|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.