No se pueden traducir correctamente los datos de caracteres de un cliente a un servidor mediante el SQL Server controlador ODBC si la página de códigos de cliente difiere de la página de códigos del servidor.

  • Artículo

Este artículo le ayuda a solucionar un problema que provoca una traducción incorrecta de datos de cliente al usar SQL Server controlador ODBC.

Versión del producto original: SQL Server
Número de KB original: 234748

Síntomas

Cuando se usa MDAC 2.1 o una versión posterior del controlador ODBC de SQL Server (versión 3.70.0623 o posterior) o el proveedor OLEDB (versión 7.01.0623 o posterior), en algunas circunstancias puede experimentar la traducción de datos de caracteres de la página de códigos de cliente a la página de códigos del servidor, incluso si Autotranslation está deshabilitado para la conexión.

Causa

Autotranslation no es el único mecanismo que puede dar lugar a la conversión de páginas de códigos. El controlador ODBC SQL Server 7.0 y el proveedor OLEDB presentan un nuevo comportamiento al conectarse a MSDE 1.0, SQL Server 7.0 o versiones posteriores de cualquiera de ellas. Todas las instrucciones SQL enviadas como un evento de lenguaje se convierten en Unicode en el cliente antes de enviarse al servidor. El efecto final es similar a un Autotranslation de todos los datos que fluyen desde el cliente al servidor a través de un evento de idioma, independientemente de la configuración actual Autotranslation de la conexión. No introducirá ninguna dificultad excepto al intentar almacenar datos de caracteres no traducidos desde una página de códigos que no sea la página de códigos de SQL Server.

Solución alternativa

No almacene datos X de la página de códigos en una página de códigos Y SQL Server (por ejemplo, datos de la página de códigos 950 en un servidor de la página de códigos 1252). Aunque esto era posible en algunas circunstancias con versiones anteriores de SQL Server, siempre se ha admitido. En un SQL Server 1252, cualquier cosa excepto un carácter 1252 no es datos de caracteres válidos. Los datos de caracteres no Unicode de una página de códigos diferente no se ordenarán correctamente y, en el caso de los datos de doble byte (DBCS), SQL Server no reconocerán correctamente los límites de caracteres. Puede causar problemas significativos.

La mejor opción para la página de códigos del SQL Server es la página de códigos de los clientes que tendrán acceso al servidor.

El servidor y el cliente pueden tener páginas de código diferentes, pero debe asegurarse de que Autotranslation está habilitado en el cliente para que obtenga la traducción adecuada de los datos hacia y desde la página de códigos del servidor en todos los casos.

Si el servidor debe almacenar datos de varias páginas de código, la solución admitida es almacenar los datos en columnas Unicode (NCHAR/NVARCHAR/NTEXT).

Si su situación requiere que almacene datos X de la página de códigos en una página de códigos Y SQL Server, solo hay dos maneras de hacerlo de forma confiable:

  • Almacene los datos en columnas binarias (BINARY/VARBINARY/IMAGE).
  • Escriba la aplicación para usar llamadas a procedimientos remotos (RPC) para todas las instrucciones SQL que se ocupan de los datos de caracteres. Los datos enviados a través de un evento RPC no están sujetos a la conversión. No hay nada en el nivel de controlador o DSN que pueda hacer para cambiar el tipo de eventos que se envían. Si un comando se envía como un idioma o un evento RPC depende completamente de las API y la sintaxis elegidas por el programador cuando se escribe la aplicación.

Más información

La traducción automática (es decir, las casillas Realizar traducción de datos de caracteres en aplicaciones ODBC más recientes) convierte los datos de caracteres de la página de códigos de cliente en la página de códigos del servidor antes de enviar los datos al servidor, usando Unicode como medio de traducción. Sin embargo, el controlador ODBC 3.7 SQL Server también convierte todas las instrucciones SQL enviadas como un evento de idioma a Unicode antes de colocarlas en la conexión, lo que tiene un efecto similar a Autotranslation pero no se rige por la configuración de Autotranslación. Por el contrario, los datos de caracteres que fluyen desde el servidor de vuelta a los clientes respetan la marca de autotranslación; si La autotranslación está desactivada, los datos llegan a la aplicación cliente con los mismos códigos de caracteres que los datos que tenían en el servidor. De forma similar, la traducción de datos para eventos RPC de cliente a servidor se puede deshabilitar desactivando La traducción automática. Un script sencillo que muestra cómo afecta el comportamiento a los eventos de lenguaje. Este ejemplo se ejecutó desde el Analizador de consultas en un cliente de la página de códigos 1252 que se conecta a un servidor de la página de códigos 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)

Lo siguiente sobre el ejemplo anterior:

  • Aunque Autotranslation estaba desactivado durante este lote, el código de caracteres 165 (yen en la página de códigos 1252) se convirtió en 157 (yen en la página de códigos 437). Esto se debe a que el controlador ODBC convirtió la cadena SQL en Unicode antes de enviarla al servidor, por lo que el servidor pudo convertirla en el carácter adecuado para el almacenamiento en la página de códigos 437.
  • Cuando el cliente ejecutó un select para recuperar los datos almacenados, el carácter 157 llegó sin traducir al cliente (157 aparece como un cuadro "" en un cliente de la página de códigos 1252). Esto se debe a que la conversión descrita en este artículo solo se aplica a los datos enviados desde el cliente al servidor, no desde el servidor al cliente. Los datos no se han traducido porque la Autotranslation configuración está desactivada.
-- 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)

En este caso, volver a activar Autotranslation no tuvo ningún efecto en la traducción del cliente al servidor (es decir, se produjo la misma traducción correcta del código de carácter 165 al código de caracteres 157), pero sí tuvo un efecto en los datos recuperados del servidor. Cuando la instrucción SELECT se ejecuta esta vez (con Autotranslation on), los símbolos yenes se muestran correctamente en la aplicación de la página de códigos 1252 porque el mecanismo los ha traducido del código de carácter 157 al código de caracteres 165 Autotranslation .

Verá este comportamiento (conversión de eventos de idioma a Unicode en el cliente) al usar cualquier SQL Server versión 3.70 o posterior del controlador ODBC y conectarse a SQL Server 7.0 o posterior. No se producirá cuando se usen controladores ODBC anteriores o cuando se use el controlador 3.7 para conectarse a SQL Server 6.5 o versiones anteriores. Además, si almacena los datos en columnas Unicode (NCHAR/NVARCHAR/NTEXT), la conversión no será un problema.

Para obtener más información sobre cómo se representan los datos de caracteres en SQL Server 2005, vea Datos de caracteres que se representan incorrectamente cuando la página de códigos del equipo cliente difiere de la página de códigos de la base de datos en SQL Server 2005.