Você não pode traduzir corretamente dados de caracteres de um cliente para um servidor usando o driver ODBC SQL Server se a página de código do cliente for diferente da página de código do servidor

Este artigo ajuda você a contornar um problema que causa a tradução incorreta de dados do cliente ao usar SQL Server driver ODBC.

Versão original do produto: SQL Server
Número de KB original: 234748

Sintomas

Ao usar o MDAC 2.1 ou posterior da versão SQL Server driver ODBC (versão 3.70.0623 ou posterior) ou o provedor OLEDB (versão 7.01.0623 ou posterior), em algumas circunstâncias, você pode experimentar a tradução de dados de caractere da página de código do cliente para a página de código do servidor, mesmo quando Autotranslation estiver desabilitado para a conexão.

Motivo

Autotranslation não é o único mecanismo que pode resultar em conversão de página de código. O SQL Server driver ODBC 7.0 e o provedor OLEDB introduzem um novo comportamento ao se conectar ao MSDE 1.0, SQL Server 7.0 ou versões posteriores de qualquer um deles. Todas as instruções SQL enviadas como um evento de idioma são convertidas em Unicode no cliente antes de serem enviadas para o servidor. O efeito final é semelhante a um Autotranslation de todos os dados que fluem do cliente para o servidor por meio de um evento de idioma, independentemente da configuração atual Autotranslation da conexão. Ele não apresentará nenhuma dificuldade, exceto ao tentar armazenar dados de caracteres não traduzidos de uma página de código diferente da página de código do SQL Server.

Solução alternativa

Não armazene dados X da página de código em uma página de código Y SQL Server (por exemplo, dados da página de código 950 em uma página de código 1252 servidor). Embora isso fosse possível em algumas circunstâncias com versões anteriores de SQL Server, sempre foi sem suporte. Para um 1252 SQL Server, tudo menos um caractere de 1252 não são dados de caracteres válidos. Os dados de caracteres não Unicode de uma página de código diferente não serão classificados corretamente e, no caso de dados DBCS (bytes duplos), SQL Server não reconhecerão os limites de caractere corretamente. Pode causar problemas significativos.

A melhor opção para a página de código do SQL Server é a página de código dos clientes que acessarão o servidor.

O servidor e o cliente podem ter páginas de código diferentes, mas você deve garantir que o Autotranslation esteja habilitado no cliente para que você obtenha a tradução adequada dos dados de e para a página de código do servidor em todos os casos.

Se o servidor precisar armazenar dados de várias páginas de código, a solução com suporte será armazenar os dados em colunas Unicode (NCHAR/NVARCHAR/NTEXT).

Se sua situação exigir que você armazene dados da página de código X em uma página de código Y SQL Server, há apenas duas maneiras de fazer isso de forma confiável:

• Armazene os dados em colunas binárias (BINARY/VARBINARY/IMAGE) colunas.
• Escreva seu aplicativo para usar RPCs (Chamadas de Procedimento Remoto) para todas as instruções SQL que lidam com dados de caracteres. Os dados enviados por meio de um evento RPC não estão sujeitos à conversão. Não há nada no nível de driver ou DSN que você possa fazer para alterar o tipo de eventos que estão sendo enviados. Se um comando é enviado como um evento de idioma ou RPC depende inteiramente das APIs e da sintaxe escolhidas pelo programador quando o aplicativo é escrito.

Mais informações

A transferência automática (ou seja, a Caixa de seleção Executar Tradução para dados de caracteres em aplicativos ODBC mais recentes) converte dados de caracteres da página de código do cliente na página de código do servidor antes de enviar os dados para o servidor, usando Unicode como um meio de tradução. No entanto, o driver ODBC 3.7 SQL Server também converte todas as instruções SQL enviadas como um evento de linguagem para Unicode antes de colocá-las no fio, o que tem um efeito semelhante à autotranslação, mas não é regido pela configuração de autotranslação. Em contraste, os dados de caracteres que fluem do servidor de volta para os clientes respeitam o sinalizador de transferência automática; se a transferência automática for desativada, os dados chegarão ao aplicativo cliente com os mesmos códigos de caracteres que os dados tinham no servidor. Da mesma forma, a tradução de dados para eventos RPC cliente-servidor pode ser desabilitada desativando a transferência automática. Um script simples que demonstra como o comportamento afeta os eventos de linguagem a seguir. Este exemplo foi executado do Analisador de Consultas em uma página de código 1252 cliente que se conecta a um servidor da página de código 437:

-- Turn Autotranslation off here.
 USE tempdb
 GO
 CREATE TABLE t1 (c1 int, c2 char(1))
 GO

-- Enter a yen character, using the keystroke ALT-0165.
 INSERT INTO t1 VALUES (1, '¥') 
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1  157

(1 row(s) affected)

O seguinte sobre o exemplo anterior:

• Embora tenha Autotranslation sido desativado durante este lote, o código de caractere 165 (iene na página de código 1252) foi convertido em 157 (iene na página de código 437). Isso ocorre porque o driver ODBC converteu a cadeia de caracteres SQL em Unicode antes de enviá-lo ao servidor, de modo que o servidor foi capaz de convertê-lo no caractere apropriado para armazenamento na página de código 437.
• Quando o cliente executou um SELECT para recuperar os dados armazenados, o caractere 157 chegou sem tradução para o cliente (157 aparece como uma caixa '' em uma página de código 1252 cliente). Isso ocorre porque a conversão discutida neste artigo se aplica apenas aos dados enviados do cliente para o servidor, não do servidor para o cliente. Os dados não foram traduzidos porque a configuração Autotranslation está desativada.

-- Turn Autotranslation back on before running the following batch.
 INSERT INTO t1 VALUES (2, '¥')
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1 ¥ 157
 2 ¥ 157

(2 row(s) affected)

Nesse caso, voltar a ativar Autotranslation não teve efeito na tradução do cliente para o servidor (ou seja, a mesma tradução correta do código de caractere 165 para o código de caractere 157 aconteceu), mas isso teve um efeito sobre os dados recuperados do servidor. Quando a instrução SELECT é executada desta vez (com Autotranslation ativado), os símbolos de iene são exibidos corretamente na página de código 1252 do aplicativo porque foram traduzidos do código de caractere 157 de volta para o Autotranslation código de caractere 165 pelo mecanismo.

Você verá esse comportamento (conversão de eventos de idioma para Unicode no cliente) ao usar qualquer SQL Server driver ODBC versão 3.70 ou posterior e conectar-se a SQL Server 7.0 ou posterior. Isso não ocorrerá ao usar drivers ODBC mais antigos ou ao usar o driver 3.7 para se conectar ao SQL Server 6.5 ou anterior. Além disso, se você estiver armazenando seus dados em colunas Unicode (NCHAR/NVARCHAR/NTEXT) a conversão não será um problema.

Para obter mais informações sobre como os dados de caracteres são representados no SQL Server 2005, consulte Dados de caracteres são representados incorretamente quando a página de código do computador cliente difere da página de código do banco de dados no SQL Server 2005.