A continuación se muestra una sección nueva que se ha añadido a este apéndice:
Una aplicación Unicode de ODBC envía y recupera datos de tipo carácter fundamentalmente en UCS-2. Efectúa esta acción llamando a las versiones de Unicode de las funciones ODBC (aquéllas que tienen el sufijo 'W') e indicando los tipos de datos de Unicode. La aplicación no especifica una página de códigos local de modo explícito. La aplicación puede seguir llamando a las funciones ANSI y pasando las series de página de códigos local.
Por ejemplo, la aplicación puede llamar a SQLConnectW() y pasar el DSN, ID de usuario y contraseña como argumentos de Unicode. A continuación, puede llamar a SQLExecDirectW(), pasar una serie de sentencia SQL de Unicode SQL y, después vincular una combinación de almacenamientos intermedios de página local ANSI (SQL_C_CHAR) y de almacenamientos intermedios Unicode (SQL_C_WCHAR). Los tipos de datos de base de datos pueden ser la página de códigos local o UCS-2 y UTF-8.
Si una aplicación CLI llama a SQLConnectW o llama a SQLSetConnectAttr con SQL_ATTR_ANSI_APP establecido en SQL_AA_FALSE, se considera que la aplicación es una aplicación Unicode. Esto significa que todos los datos CHAR se envían y reciben desde la base de datos en formato UTF-8. A continuación, la aplicación puede captar datos CHAR en almacenamientos intermedios SQL_C_CHAR de la página de códigos local (con una posible pérdida de datos), o en almacenamientos intermedios SQL_C_WCHAR en UCS-2 sin pérdida de datos.
Si la aplicación no efectúa ninguna de las dos llamadas anteriores, los datos CHAR se convierten a la página de códigos local de las aplicaciones del servidor. Lo cual significa que los datos CHAR que se captan en SQL_C_WCHAR pueden experimentar una pérdida de datos.
Si la variable de instancia de DB2CODEPAGE se establece (utilizando db2set) en la página de códigos 1208 (UTF-8), la aplicación recibirá todos los datos CHAR en UTF-8 ya que ésta es ahora la página de códigos local. La aplicación debe asegurarse también de que todos los datos de entrada CHAR estén asimismo en UTF-8. ODBC asume asimismo que todos los datos SQL_C_WCHAR están en formato endian nativo. CLI efectuará la alternancia de bytes que se necesite para SQL_C_WCHAR.
Este release de DB2 Universal Database contiene la API de SQLConnectW(). Un controlador Unicode debe exportar SQLConnectW para que el gestor de controladores lo reconozca como controlador Unicode. Es importante tener en cuenta que numerosas aplicaciones de ODBC (por ejemplo Microsoft Access y Visual Basic) llaman a SQLConnectW(). En los releases anteriores de DB2 Universal Database, DB2 CLI no daba soporte a esta API y, por tanto el gestor de controladores de ODBC no lo reconocía como controlador Unicode. Esto hacía que el gestor de controladores de ODBC convirtiera todos los datos de Unicode a la página de códigos local de la aplicación. Con el soporte añadido de la función SQLConnectW(), estas aplicaciones se convertirán ahora en aplicaciones Unicode y DB2 CLI asumirá todas las conversiones de datos necesarias.
DB2 CLI acepta en este momento las API de Unicode (con un sufijo de "W") y las API de ANSI habituales. ODBC define un conjunto de funciones con un sufijo de "A", pero el gestor de controladores no pasa funciones de ANSI con el sufijo "A" al controlador. En vez de eso, convierte dichas funciones en llamadas de función de ANSI sin el sufijo y después las pasa al controlador.
Una aplicación de ODBC que llama a la API de SQLConnectW() se considera que es una aplicación Unicode. Puesto que el gestor de controladores de ODBC siempre llamará a la API de SQLConnectW() sin tener en cuenta la versión de la aplicación llamada, ODBC introducirá el atributo de conexión SQL_ATTR_ANSI_APP para notificar al controlador si la aplicación debería considerarse una aplicación ANSI o UNICODE. Si SQL_ATTR_ANSI_APP no se establece en SQL_AA_FALSE, DB2 CLI convierte todos los datos de Unicode a la página de códigos local antes de enviarlos al servidor.