|The following is a new section added to this appendix.
|A Unicode ODBC application sends and retrieves character data primarily |in UCS-2. It does this by calling Unicode versions of the ODBC functions |(those with a 'W' suffix) and by indicating Unicode data types. The application |does not explicitly specify a local code page. The application can still |call the ANSI functions and pass local code page strings.
|For example, the application may call SQLConnectW() and pass the DSN, |User ID and Password as Unicode arguments. It may then call SQLExecDirectW() |and pass in a Unicode SQL statement string, and then bind a combination of |ANSI local code page buffers (SQL_C_CHAR) and Unicode buffers (SQL_C_WCHAR). |The database data types may be local code page or UCS-2 and UTF-8.
|If a CLI application calls SQLConnectW or calls SQLSetConnectAttr with |SQL_ATTR_ANSI_APP set to SQL_AA_FALSE, the application is considered a Unicode |application. This means all CHAR data is sent and received from the database |in UTF-8 format. The application can then fetch CHAR data into SQL_C_CHAR |buffers in local code page (with possible data loss), or into SQL_C_WCHAR |buffers in UCS-2 without any data loss.
|If the application does not do either of the two calls above, CHAR data |is converted to the applications local code page at the server. This means |CHAR data fetched into SQL_C_WCHAR may suffer data loss.
|If the DB2CODEPAGE instance variable is set (using db2set) to code page |1208 (UTF-8), the application will receive all CHAR data in UTF-8 since this |is now the local code page. The application must also ensure that all CHAR |input data is also in UTF-8. ODBC also assumes that all SQL_C_WCHAR data is |in the native endian format. CLI will perform any required byte-reversal |for SQL_C_WCHAR.
|This release of DB2 Universal Database contains the SQLConnectW() API. |A Unicode driver must export SQLConnectW in order to be recognized as a Unicode |driver by the driver manager. It is important to note that many ODBC applications |(such as Microsoft Access and Visual Basic) call SQLConnectW(). In previous |releases of DB2 Universal Database, DB2 CLI has not supported this API, and |thus was not recognized as a Unicode driver by the ODBC driver manager. |This caused the ODBC driver manager to convert all Unicode data to the application's |local code page. With the added support of the SQLConnectW() function, these |applications will now connect as Unicode applications and DB2 CLI will take |care of all required data conversion.
|DB2 CLI now accepts Unicode APIs (with a suffix of "W") and regular ANSI |APIs. ODBC defines a set of functions with a suffix of "A", but the driver |manager does not pass ANSI functions with the "A" suffix to the driver. Instead, |it converts these functions to ANSI function calls without the suffix, and |then passes them to the driver.
|An ODBC application that calls the SQLConnectW() API is considered a Unicode |application. Since the ODBC driver manager will always call the SQLConnectW() |API regardless of what version the application called, ODBC introduced the |SQL_ATTR_ANSI_APP connect attribute to notify the driver if the application |should be considered an ANSI or UNICODE application. If SQL_ATTR_ANSI_APP |is not set to SQL_AA_FALSE, DB2 CLI converts all Unicode data to the local |code page before sending it to the server.