No traduce correctamente los datos de caracteres desde un cliente a un servidor utilizando el controlador ODBC de SQL Server si la página de códigos cliente difiere de la página de códigos del servidor


Síntomas


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

Causa


Autotranslation no es el único mecanismo que puede resultar en la conversión de páginas de código. El controlador ODBC de SQL Server 7.0 y el proveedor OLEDB de introducen un nuevo comportamiento al conectarse a MSDE 1.0, SQL Server 7.0 o versiones posteriores de uno de ellos. Todas las instrucciones de SQL enviadas como un evento de lenguaje se convierten a Unicode en el cliente antes de ser enviados al servidor. El efecto final es similar a un Autotranslation de todos los datos que fluyen desde el cliente al servidor mediante un evento de lenguaje, independientemente de la configuración de Autotranslation actual para la conexión. No introducirá dificultades excepto cuando intenta almacenar datos de carácter no traducido de una página de códigos distinta de la página de códigos de SQL Server.

Solución alternativa


No almacene datos de página X de código en una página de códigos Y de SQL Server (por ejemplo, código página 950 datos en un servidor de código de página 1252). Si esto era posible en algunas circunstancias con las versiones anteriores de SQL Server, siempre ha sido no compatible. A un SQL Server 1252, cualquier cosa menos un 1252 carácter no es datos de carácter válido. Datos de caracteres no Unicode de una página de códigos diferente no se ordenarán correctamente y, en el caso de datos de doble byte (DBCS), SQL Server no reconocerá los límites de caracteres correctamente. Esto puede causar problemas importantes, como el problema descrito en el artículo siguiente en Microsoft Knowledge Base:
155723 INF: truncamiento de SQL Server de una cadena DBCS

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

El servidor y el cliente pueden tener diferentes páginas de códigos, pero debe asegurarse de que Autotranslation está habilitada en el cliente para que obtenga una conversión correcta de datos desde la página de códigos del servidor y en todos los casos.

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

Si su situación requiere que almacene datos de página X de código en una página de códigos Y SQL Server, hay sólo dos maneras de hacerlo de forma confiable:
  • Almacenar los datos en columnas de columnas binarias (BINARY o VARBINARY o IMAGE).
  • Escribir la aplicación para utilizar llamadas a procedimiento remoto (RPC) para todas las instrucciones SQL que tratan con datos de caracteres. Datos enviados a través de un evento RPC no están sujeto a esta conversión. Tenga en cuenta que no hay nada en el nivel DSN que puede hacer para cambiar el tipo de eventos que se envían o controlador. Si se ha enviado un comando como un idioma o un evento RPC depende completamente de la API y la sintaxis elegido por el programador cuando la aplicación está escrita.

Más información


Autotranslation (es decir, las casillas "Realizar conversión de los datos de caracteres" en las aplicaciones ODBC más recientes) convierte datos de caracteres de la página de códigos del cliente a la página de códigos del servidor antes de enviar los datos al servidor, utilizando Unicode como un medio de traducción. Sin embargo, el controlador ODBC de SQL Server 3.7 también convierte todas las instrucciones SQL que se envían como un evento de lenguaje a Unicode antes de colocarlos en el cable, que tiene un efecto que es similar a Autotranslation, pero no se rige por la configuración de Autotranslation. Por el contrario, los datos de caracteres que fluyen desde el servidor a los clientes respetan el indicador Autotranslation; Si Autotranslation está desactivado los datos llegan al cliente aplicación con los mismos códigos de carácter como los datos que había en el servidor. De forma similar, se puede deshabilitar la traducción de datos para los eventos de cliente a servidor RPC desactivando Autotranslation. Sigue una secuencia de comandos simple que muestra cómo este comportamiento afecta a eventos del lenguaje. En este ejemplo se ejecutó desde el analizador de consultas de un cliente de código página 1252 conectarse a un servidor 437 de página de código:
-- 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)
Tenga en cuenta lo siguiente sobre el ejemplo anterior:
  • Aunque Autotranslation estaba apagado durante este proceso, el código de carácter 165 (yen en la página de códigos 1252) se convirtió en 157 (yen en la página de códigos 437). Esto es porque el controlador ODBC convierte la cadena SQL a Unicode antes de enviarlo el servidor, por lo que el servidor fue capaz de convertirlo en el carácter apropiado para su almacenamiento en la página de códigos 437.
  • Cuando el cliente ejecutó un Seleccione para recuperar los datos que simplemente se han almacenado, el carácter 157 llegado no traducido en el cliente (157 se muestra como un cuadro "" en un cliente de página 1252 de código). Esto es porque la conversión descrita en este artículo sólo se aplica a los datos enviados desde el cliente al servidor, no desde el servidor al cliente. Los datos no se ha traducido porque la configuración de Autotranslation 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, vuelva a activar Autotranslation no tenía efecto en la traducción desde el cliente al servidor (es decir, si ha ocurrido la misma traducción correcta desde el código de carácter 165 al código de carácter 157), pero tenía un efecto en los datos recuperados desde el servidor. Tenga en cuenta que cuando la instrucción SELECT se ejecuta esta vez (con Autotranslation en), los símbolos de yen se muestran correctamente en la aplicación de código página 1252 debido a han sido traducidos desde el código de carácter 157 al código de carácter 165 por el Autotranslation mecanismo.

Verá este comportamiento (conversión de sucesos de lenguaje a Unicode en el cliente) cuando utilizando cualquier ODBC de SQL Server versión 3.70 o posterior y conexión a SQL Server 7.0 o posterior del controlador. No se producirá al utilizar los controladores ODBC más antiguos, o cuando se utiliza el controlador 3.7 para conectarse a SQL Server 6.5 o anterior. Además, si está almacenando los datos en columnas Unicode (NCHAR/NVARCHAR y NTEXT) la conversión no será un problema.
Para obtener más información acerca de cómo se representan los datos de caracteres en SQL Server 2005, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

904803 datos de caracteres 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