|Дальше приведен новый раздел для этого приложения.
|Прикладные программы ODBC Unicode отправляют и получают символьные данные |главным образом в формате UCS-2. Это происходит путем вызова |Unicode-версий функций ODBC (с суффиксом 'W') и указания типов |данных Unicode. Прикладная программа не указывает локальную кодовую |страницу явно. Она сохраняет способность взывать функции ANSI и |передавать строки в кодировке локальной кодовой таблицы.
|Например, прикладная программа может вызвать SQLConnectW() и передать ID |пользователя и пароль DSN как аргументы Unicode. После этого она может |вызвать SQLExecDirectW() и передать строку оператора SQL Unicode, а затем |связать комбинацию буферов страниц ANSI с локальной кодировкой (SQL_C_CHAR) и |буферов Unicode (SQL_C_WCHAR). Типом данных базы данных может быть |локальная кодовая страница или UCS-2 и UTF-8.
|Если прикладная программа CLI вызывает SQLConnectW или вызывает |SQLSetConnectAttr со значением SQL_AA_FALSE для SQL_ATTR_ANSI_APP, эта |прикладная программа считается программой Unicode. Это означает, что |все данные CHAR посылаются базе данных и принимаются от нее в формате |UTF-8. После этого прикладная программа может считывать данные CHAR в |буфера SQL_C_CHAR в кодировке локальной кодовой страницы (с возможной потерей |данных) или в буфера SQL_C_WCHAR в UCS-2 без какой-либо потери данных.
|Если прикладная программа не выполняет любой из описанных выше вызовов, |данные CHAR на сервере преобразуются в локальную страницу прикладной |программы. Это означает, что в данных CHAR, считанных в SQL_C_WCHAR, |возможны потери.
|Если для переменной экземпляра DB2CODEPAGE установлена (с использованием |db2set) кодовая страница 1208 (UTF-8), прикладная программа будет получать все |данные CHAR в UTF-8, поскольку теперь это новая локальная страница. |Прикладная программа должна также проверить, что все входные данные CHAR тоже |находятся в UTF-8. ODBC подразумевает также, что все данные SQL_C_WCHAR |находятся в собственном конечном формате. CLI будет выполнять все |необходимые обращения байтов для SQL_C_WCHAR.
|В этом выпуске DB2 Universal Database есть API SQLConnectW(). |Драйвер Unicode должен экспортировать SQLConnectW, чтобы быть опознанным |драйвером менеджеров как драйвер Unicode. Важно заметить, что многие из |прикладных программ ODBC (такие как Microsoft Access и Visual Basic) вызывают |SQLConnectW(). В предыдущих выпусках DB2 Universal Database CLI DB2 не |поддерживали этот API, и поэтому он не распознавался менеджером драйверов ODBC |как драйвер Unicode. Это приводило к тому, что менеджер драйверов ODBC |преобразовывал все драйверы Unicode в локальную кодовую страницу прикладной |программы. При добавлении поддержки функции SQLConnectW() эти |прикладные программы не будут устанавливать связь как программы Unicode, а все |необходимые преобразования данных возьмет на себя CLI DB2.
|Теперь CLI DB2 принимает API Unicode API (с суффиксом "W") и стандартные |API ANSI. ODBC определяет набор функций с суффиксом "A", но менеджер |драйверов не пропускает к драйверу функции ANSI с суффиксом "A". Вместо |этого он преобразует эти функции в вызовы функций ANSI без этого суффикса, а |затем передает их драйверу.
|Прикладная программа ODBC, вызывающая API SQLConnectW(), считается |прикладной программой Unicode. Так как менеджер драйверов ODBC всегда |будет вызывать API SQLConnectW() независимо от версии вызываемой прикладной |программы, ODBC теперь использует атрибут связи SQL_ATTR_ANSI_APP для |уведомления драйвера о том, что она должна рассматриваться как прикладная |программа ANSI или UNICODE. Если для SQL_ATTR_ANSI_APP не установлено |SQL_AA_FALSE, перед отправкой его на сервер CLI DB2 преобразует все данные |Unicode в локальную кодовую страницу.