DB2 10.5 for Linux, UNIX, and Windows

Unicode CLI applications

The CLI Unicode application must connect to the database with either the SQLConnectW() or SQLDriverConnectW() function. The connecting to the database with either the SQLConnectW() or SQLDriverConnectW() function ensures that the CLI driver considers Unicode as the preferred method of communication between itself and the database.

There are two main areas of support for CLI Unicode applications:

The addition of a set of functions that accept Unicode string arguments in place of ANSI string arguments.
The addition of new C and SQL data types to describe Unicode data.

ODBC adds types to the set of C and SQL types that already exist to accommodate Unicode, and CLI uses these additional types accordingly. The new C type, SQL_C_WCHAR, indicates that the C buffer contains Unicode data. The CLI/ODBC driver considers all Unicode data exchanged with the application to be UCS-2 in native-endian format. The new SQL types, SQL_WCHAR, SQL_WVARCHAR, and SQL_WLONGVARCHAR, indicate that a particular column or parameter marker contains Unicode data. For DB2® Unicode databases, graphic columns are described using the new types. Conversion is allowed between SQL_C_WCHAR and SQL_CHAR, SQL_VARCHAR, SQL_LONGVARCHAR and SQL_CLOB, as well as with the graphic data types.

Note: UCS-2 is a fixed-length character encoding scheme that uses 2 bytes to represent each character. When referring to the number of characters in a UCS-2 encoded string, the count is simply the number of SQLWCHAR elements needed to store the string.

Obsolete CLI/ODBC keyword values

Before Unicode applications were supported, applications that were written to work with single-byte character data could be made to work with double-byte graphic data by a series of CLI configuration keywords, such as Graphic=1,2 or 3, Patch2=7. These workarounds presented graphic data as character data, and also affected the reported length of the data. These keywords are no longer required for Unicode applications, and should not be used due to the risk of potential side effects. If it is not known if a particular application is a Unicode application, try without any of the keywords that affect the handling of graphic data.

Literals in unicode databases

In non-Unicode databases, data in LONG VARGRAPHIC and LONG VARCHAR columns cannot be compared. Data in GRAPHIC/VARGRAPHIC and CHAR/VARCHAR columns can only be compared, or assigned to each other, using explicit cast functions since no implicit code page conversion is supported. This includes GRAPHIC/VARGRAPHIC and CHAR/VARCHAR literals where a GRAPHIC/VARGRAPHIC literal is differentiated from a CHAR/VARCHAR literal by a G prefix. For Unicode databases, casting between GRAPHIC/VARGRAPHIC and CHAR/VARCHAR literals is not required. Also, a G prefix is not required in front of a GRAPHIC/VARGRAPHIC literal. Provided at least one of the arguments is a literal, implicit conversions occur. This allows literals with or without the G prefix to be used within statements that use either SQLPrepareW() or SQLExecDirect(). Literals for LONG VARGRAPHICs still must have a G prefix.