|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 or may not be |Unicode.
|If a CLI application calls SQLSetConnectAttr with SQL_ATTR_ANSI_APP set to |SQL_AA_FALSE or calls SQLConnectW without setting the value of |SQL_ATTR_ANSI_APP, then the application is considered a Unicode |application. This means all CHAR data is sent and received from a |Unicode 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 set to SQL_AA_TRUE, the DB2 CLI converts all Unicode data |to the local code page before sending it to the server.