Esta é uma nova seção incluída nesse apêndice.
Um aplicativo Unicode do ODBC envia e recupera dados de caractere primeiramente no UCS-2. Isso é feito chamando as versões Unicode das funções ODBC (aquelas com um sufixo 'W') e indicando tipos de dados Unicode. O aplicativo não especifica explicitamente uma página de códigos local. Ela ainda pode chamar as funções ANSI e passar as cadeias da página de códigos local.
Por exemplo, o aplicativo pode chamar SQLConnectW() e passar o DSN, o ID do Usuário e a Senha como argumentos do Unicode. Então, ela pode chamar SQLExecDirectW() e passar uma cadeia de instrução SQL do Unicode e vincular uma combinação de buffers da página de códigos local ANSI (SQL_C_CHAR) e de buffers Unicode (SQL_C_WCHAR). Os tipos de dados do banco de dados podem ser ou não Unicode.
Se um aplicativo CLI chamar SQLSetConnectAttr com SQL_ATTR_ANSI_APP definido para SQL_AA_FALSE ou chamar SQLConnectW sem definir o valor de SQL_ATTR_ANSI_APP, então, o aplicativo é considerado um aplicativo Unicode. Isso significa que todos os dados CHAR são enviados e recebidos de um banco de dados Unicode no formato UTF-8. O aplicativo poderá então buscar os dados CHAR nos buffers SQL_C_CHAR na página de códigos local (com possível perda de dados) ou nos buffers SQL_C_WCHAR no UCS-2 sem perda de dados.
Se o aplicativo não fizer nenhuma das duas chamadas anteriores, os dados CHAR serão convertidos para a página de códigos local dos aplicativos no servidor. Isso significa que os dados CHAR buscados em SQL_C_WCHAR poderão sofrer perda de dados.
Se a variável de instância DB2CODEPAGE for definida (utilizando db2set) para a página de códigos 1208 (UTF-8), o aplicativo receberá todos os dados CHAR em UTF-8, porque essa é agora a página de códigos local. O aplicativo também deve assegurar que todos os dados de entrada CHAR também estejam em UTF-8. O ODBC também assume que todos os dados SQL_C_WCHAR estão no formato endian nativo. A CLI executará toda a reversão de bytes requerida para SQL_C_WCHAR.
Este release do DB2 Universal Database contém a APISQLConnectW(). Um driver Unicode deve exportar SQLConnectW para ser reconhecido como um driver Unicode pelo gerenciador de driver. É importante observar que muitos aplicativos ODBC (como o Microsoft Access e o Visual Basic) chamam SQLConnectW(). Em releases anteriores do DB2 Universal Database, o DB2 CLI não suportava essa API e, portanto, não era reconhecido como um driver Unicode pelo gerenciador de driver ODBC. Isso fazia com que o gerenciador de driver ODBC convertesse todos os dados Unicode para a página de códigos local do aplicativo. Com o suporte incluído da função SQLConnectW(), esses aplicativos agora serão conectados como aplicativos Unicode e o DB2 CLI cuidará de todas as conversões de dados necessárias.
O DB2 CLI agora aceita APIs Unicode (com um sufixo "W") e APIs ANSI comuns. O ODBC define um conjunto de funções com um sufixo "A", mas o gerenciador de driver não passa funções ANSI com o sufixo "A" para o driver. Ao invés disso, ele converte essas funções para chamadas de função ANSI sem o sufixo e, então, as passa ao driver.
Um aplicativo ODBC que chama a API SQLConnectW() é considerado um aplicativo Unicode. Como o gerenciador de driver ODBC sempre chamará a API SQLConnectW() independente da versão do aplicativo chamado, o ODBC introduziu o atributo de conexão SQL_ATTR_ANSI_APP para notificar a unidade, se o aplicativo precisar ser considerado um aplicativo ANSI ou UNICODE. Se SQL_ATTR_ANSI_APP for definido para SQL_AA_TRUE, o DB2 CLI converterá todos dados Unicode para a página de códigos local antes de enviá-lo ao servidor.