Дальше приведен новый раздел для этой главы.
Существуют две основных области поддержки для прикладных программ Unicode CLI DB2:
Далее приводится список функций API ODBC, которые поддерживают версии как Unicode (W), так ANSI (A) (в Unicode в имени функции будет присутствовать W):
SQLBrowseConnect SQLForeignKeys SQLPrimaryKeys SQLColAttribute SQLGetConnectAttr SQLProcedureColumns SQLColAttributes SQLGetConnectOption SQLProcedures SQLColumnPrivileges SQLGetCursorName SQLSetConnectAttr SQLColumns SQLGetDescField SQLSetConnectOption SQLConnect SQLGetDescRec SQLSetCursorName SQLDataSources SQLGetDiagField SQLSetDescField SQLDescribeCol SQLGetDiagRec SQLSetStmtAttr SQLDriverConnect SQLGetInfo SQLSpecialColumns SQLDrivers SQLGetStmtAttr SQLStatistics SQLError SQLNativeSQL SQLTablePrivileges SQLExecDirect SQLPrepare SQLTables
Функции Unicode всегда возвращают или принимают аргументы длины строки в виде числа символов. Для функций, возвращающих информацию о длине для данных сервера, размер и точность вывода на экран описываются числом символов. Когда длина (размер передаваемых данных) может относиться и к строчным, и к другим данным, эта длина описывается в длинах октетов. Например, для SQLGetInfoW длина - это число байтов, а для SQLExecDirectW - число символов. CLI будет возвращать наборы результатов либо в Unicode, либо в ANSI, в зависимости от связывания прикладной программы. Если прикладная программа связывается с SQL_C_CHAR, драйвер будет преобразовывать данные SQL_WCHAR в SQL_CHAR. Менеджер драйверов отображает SQL_C_WCHAR в SQL_C_CHAR для драйверов ANSI, но не производит отображения для драйверов Unicode.
Есть два новых определенных типа данных CLI или ODBC, SQL_C_WCHAR и SQL_WCHAR. SQL_C_WCHAR указывает, что буфер C содержит данные UCS-2. SQL_WCHAR указывает, что маркер конкретного столбца или параметра содержит данные Unicode. Для серверов Unicode DB2 графические столбцы будут описываться как SQL_WCHAR. Преобразование будет разрешено между SQL_C_WCHAR и SQL_CHAR, SQL_VARCHAR, SQL_LONGVARCHAR и SQL_CLOB, а также между графическими типами данных.
Табл. 21. Поддерживаемые преобразования данных
Тип данных SQL |
S Q L _ C _ C H A R |
S Q L _ C _ W C H A R |
S Q L _ C _ L O N G |
S Q L _ C _ S H O R T |
S Q L _ C _ T I N Y I N T |
|
S Q L _ C _ D O U B L E |
S Q L _ C _ T Y P E _ D A T E |
S Q L _ C _ T Y P E _ T I M E |
S Q L _ C _ T Y P E _ T I M E S T A M P |
S Q L _ C _ B I N A R Y |
S Q L _ C _ B I T |
S Q L _ C _ D B C H A R |
S Q L _ C _ C L O B _ L O C A T O R |
S Q L _ C _ B L O B _ L O C A T O R |
S Q L _ C _ D B C L O B _ L O C A T O R |
S Q L _ C _ B I G I N T |
S Q L _ C _ N U M E R I C |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
BLOB |
X |
X |
|
|
|
|
|
|
|
|
D |
|
|
|
X |
|
|
|
CHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
|
X |
X |
CLOB |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
X |
|
|
|
|
DATE |
X |
X |
|
|
|
|
|
D |
|
X |
|
|
|
|
|
|
|
|
DBCLOB |
|
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
X |
|
|
DECIMAL |
D |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
|
X |
X |
DOUBLE |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
|
X |
X |
FLOAT |
X |
X |
X |
X |
X |
X |
D |
|
|
|
|
X |
|
|
|
|
X |
X |
GRAPHIC (Не Unicode) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
|
|
|
|
GRAPHIC (Unicode) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
INTEGER |
X |
X |
D |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
|
X |
X |
LONG VARCHAR |
D |
X |
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
LONG VARGRAPHIC (Не Unicode) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
|
|
|
LONG VARGRAPHIC (Unicode) |
X |
X |
|
|
|
|
|
|
|
|
X |
|
D |
|
|
|
|
|
NUMERIC |
D |
X |
X |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
|
|
X |
REAL |
X |
X |
X |
X |
X |
D |
X |
|
|
|
|
X |
|
|
|
|
|
X |
SMALLINT |
X |
X |
X |
D |
X |
X |
X |
|
|
|
|
X |
|
|
|
|
X |
X |
BIGINT |
X |
X |
X |
X |
X |
X |
X |
|
|
|
X |
X |
|
|
|
|
D |
X |
TIME |
X |
X |
|
|
|
|
|
|
D |
X |
|
|
|
|
|
|
|
|
TIMESTAMP |
X |
X |
|
|
|
|
|
X |
X |
D |
|
|
|
|
|
|
|
|
VARCHAR |
D |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
|
|
X |
X |
VARGRAPHIC (Не Unicode) |
X |
X |
|
|
|
|
|
|
|
|
|
|
D |
|
|
|
|
|
VARGRAPHIC (Unicode) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
D |
|
|
|
X |
|
Прим.: |
|
До того, как стали поддерживаться прикладные программы Unicode, программы, написанные для работы с однобайтными символьными данными, можно было заставить работать с двухбайтными графическими данными при помощи нескольких последовательных ключевых слов файлов cli ini, таких как GRAPHIC=1,2 или 3, Patch2=7 и т. д. Такой подход представляет графические данные как символьные и оказывает влияние на сообщаемую длину данных.
Для прикладных программ Unicode такие ключевые слова теперь не нужны, и, более того, они не должны использоваться, поскольку могут вызывать серьезные побочные эффекты. Если достоверно не известно, является ли конкретная прикладная программа программой Unicode, советуем попробовать обойтись без ключевых слов, влияющих на обработку графических данных.
В базах данных не Unicode нельзя сравнивать данные в столбцах LONG VARGRAPHIC и LONG VARCHAR. Столбцы GRAPHIC/VARGRAPHIC и CHAR/VARCHAR можно только сравнивать или назначать друг другу, явным образом используя функции преобразования типов, поскольку неявное преобразование кодовых страниц не поддерживается как таковое. Это относится к литералам GRAPHIC/VARGRAPHIC и CHAR/VARCHAR, когда литерал GRAPHIC/VARGRAPHIC отличается от литерала CHAR/VARCHAR при помощи префикса G.
В базах данных Unicode не требуется преобразование между литералами GRAPHIC/VARGRAPHIC и CHAR/VARCHAR. Кроме того, в них перед литералом GRAPHIC/VARGRAPHIC не требуется префикс G. Если, по крайней мере, один из аргументов является литералом, происходят неявные преобразования. Это позволяет применять литералы с префиксом G или без него в операторах, использующих либо SQLPrepareW(), либо SQLExecDirect(). При этом литералы для LONG VARGRAPHIC могут сохранять префикс G.
Дополнительную информацию смотрите в разделе "Casting Between Data Types" Главы 3 Language Elements справочника SQL Reference.
С целью устранения дополнительных издержек при связи прикладных программ Unicode с базой данных были добавлены следующие три ключевых слова.
Если сначала разрешить поддержку Unicode, а затем вызвать прикладную программу Unicode, CLI попробует связаться с базой данных и использованием кодовой страницы клиента, лучше всех обеспечивающей отсутствие дополнительных потерь данных, связанных с преобразованием кодовых страниц. Это может увеличить время соединения за счет обмена кодовых страниц, а также вызвать преобразование кодовых страниц на клиенте, которого не было до добавления этой поддержки.
Задание значения True для этого ключевого слова значения приведет к преобразованию всех данных Unicode в локальную кодовую страницу прикладной программы перед их отправкой на сервер. Это может привести к потере любых данных, которые нельзя представить в локальной кодовой странице.
Прикладные программы не Unicode всегда связываются с базой данных, используя локальную страницу прикладной программы или установку среды кодовой страницы DB2. По умолчанию CLI будет обеспечивать связь прикладных программ Unicode с базами данных Unicode с использованием кодовых страниц UTF-8 и UCS-2, а с базами данных не Unicode - с использованием кодовых страниц этих баз данных. Этим предотвращается необязательная потеря данных из-за преобразования кодовых страниц.
Это ключевое слово позволяет пользователю указывать кодовую страницу базы данных при связывании с базой данных не Unicode, чтобы при этом соединении не производились ненужные дополнительные затраты.
Укажите значение 1, чтобы SQLDriverConnect() возвращало правильное значение в строке вывода соединения, чтобы использовать это значение при последующих вызовах SQLDriverConnect().
Это ключевое слово эквивалентно ConnectCodepage=1208 и добавлено только для удобства. Установите это ключевое слово для предотвращения избыточных расходов на связь с DB2 for OS/390 Версии 7 или более поздней. Нет необходимости устанавливать это ключевое слово для баз данных DB2 for Windows, DB2 for Unix или DB2 for OS/2, поскольку при этом не требуется дополнительная обработка.
Дальше приведен новый раздел для этого приложения.
Прикладные программы 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 в локальную кодовую страницу.