Vous ne pouvez pas traduire correctement les données de caractères d’un client vers un serveur à l’aide du pilote ODBC SQL Server si la page de codes du client diffère de la page de codes du serveur

Cet article vous aide à contourner un problème qui provoque une traduction incorrecte des données client lors de l’utilisation de SQL Server pilote ODBC.

Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 234748

Symptômes

Lors de l’utilisation de MDAC 2.1 ou version ultérieure du pilote ODBC SQL Server (version 3.70.0623 ou ultérieure) ou du fournisseur OLEDB (version 7.01.0623 ou ultérieure), dans certains cas, vous pouvez rencontrer la traduction de données de caractères de la page de codes client vers la page de codes du serveur, même lorsque Autotranslation est désactivé pour la connexion.

Cause

Autotranslation n’est pas le seul mécanisme qui peut entraîner une conversion de page de codes. Le pilote ODBC SQL Server 7.0 et le fournisseur OLEDB introduisent un nouveau comportement lors de la connexion à MSDE 1.0, SQL Server 7.0 ou versions ultérieures de l’un ou l’autre des deux. Toutes les instructions SQL envoyées en tant qu’événement de langage sont converties en Unicode sur le client avant d’être envoyées au serveur. L’effet final est similaire à celui de Autotranslation toutes les données transmises du client au serveur via un événement de langue, quel que soit le paramètre actuel Autotranslation de la connexion. Cela n’introduit aucune difficulté, sauf lors de la tentative de stockage des données de caractères non traduites à partir d’une page de codes autre que la page de codes de SQL Server.

Solution de contournement

Ne stockez pas les données X de la page de codes dans une page de codes Y SQL Server (par exemple, les données de la page de codes 950 dans un serveur de page de codes 1252). Bien que cela ait été possible dans certaines circonstances avec les versions précédentes de SQL Server, cela n’a toujours pas été pris en charge. Pour une SQL Server 1252, tout ce qui n’est qu’un caractère 1252 n’est pas des données de caractères valides. Les données caractères non Unicode d’une autre page de codes ne seront pas triées correctement et, dans le cas de données codées sur deux octets (DBCS), SQL Server ne reconnaîtront pas correctement les limites des caractères. Il peut causer des problèmes importants.

Le meilleur choix pour la page de codes du SQL Server est la page de codes des clients qui accèderont au serveur.

Le serveur et le client peuvent avoir des pages de codes différentes, mais vous devez vous assurer que la traduction automatique est activée sur le client afin d’obtenir une traduction appropriée des données vers et à partir de la page de codes du serveur dans tous les cas.

Si votre serveur doit stocker des données à partir de plusieurs pages de codes, la solution prise en charge consiste à stocker les données dans des colonnes Unicode (NCHAR/NVARCHAR/NTEXT).

Si votre situation nécessite que vous stockiez les données de la page de codes X dans une page de codes Y SQL Server, il n’existe que deux façons de procéder de manière fiable :

• Stockez les données dans des colonnes binaires (BINARY/VARBINARY/IMAGE).
• Écrivez votre application pour utiliser des appels de procédure distante (RPC) pour toutes les instructions SQL qui traitent des données de caractères. Les données envoyées via un événement RPC ne sont pas soumises à la conversion. Il n’y a rien au niveau du pilote ou du DSN que vous pouvez faire pour modifier le type d’événements envoyés. Le fait qu’une commande soit envoyée en tant que langage ou événement RPC dépend entièrement des API et de la syntaxe choisies par le programmeur lors de l’écriture de l’application.

Plus d’informations

La conversion automatique (c’est-à-dire la case à cocher Effectuer la traduction des données caractères dans les applications ODBC plus récentes) convertit les données de caractères de la page de codes du client en page de codes du serveur avant d’envoyer les données au serveur, en utilisant Unicode comme support de traduction. Toutefois, le pilote ODBC 3.7 SQL Server convertit également toutes les instructions SQL envoyées en tant qu’événement de langage en Unicode avant de les placer sur le câble, ce qui a un effet similaire à la conversion automatique mais n’est pas régi par le paramètre de traduction automatique. En revanche, les données caractères qui circulent du serveur vers les clients respectent l’indicateur de traduction automatique ; si la traduction automatique est désactivée, les données arrivent à l’application cliente avec les mêmes codes de caractères que les données sur le serveur. De même, la traduction de données pour les événements RPC client-à-serveur peut être désactivée en désactivant la traduction automatique. Script simple qui montre comment le comportement affecte les événements de langage. Cet exemple a été exécuté à partir de l’Analyseur de requêtes sur un client de page de codes 1252 se connectant à un serveur de page de codes 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)

Voici ce qui suit à propos de l’exemple précédent :

• Même si Autotranslation était désactivé pendant ce lot, le code de caractère 165 (yen dans la page de codes 1252) a été converti en 157 (yen dans la page de codes 437). Cela est dû au fait que le pilote ODBC a converti la chaîne SQL en Unicode avant de l’envoyer au serveur, de sorte que le serveur a pu la convertir en caractère approprié pour le stockage dans la page de codes 437.
• Lorsque le client a exécuté une instruction SELECT pour récupérer les données qui avaient été stockées, le caractère 157 est arrivé non traduit sur le client (157 s’affiche sous la forme d’une zone « » sur un client de page de codes 1252). En effet, la conversion décrite dans cet article s’applique uniquement aux données envoyées du client au serveur, et non du serveur au client. Les données n’ont pas été traduites, car le Autotranslation paramètre est désactivé.

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

Dans ce cas, Autotranslation la restauration n’a eu aucun effet sur la traduction du client vers le serveur (autrement dit, la même traduction correcte du code de caractère 165 au code de caractère 157 s’est produite), mais elle a eu un effet sur les données récupérées à partir du serveur. Lorsque l’instruction SELECT est exécutée cette fois (avec Autotranslation activé), les symboles yen s’affichent correctement dans l’application de la page de codes 1252, car ils ont été traduits du code de caractère 157 au code de caractère 165 par le Autotranslation mécanisme.

Vous verrez ce comportement (conversion d’événements de langage en Unicode sur le client) lors de l’utilisation d’un pilote ODBC SQL Server version 3.70 ou ultérieure et de la connexion à SQL Server 7.0 ou version ultérieure. Cela ne se produit pas lors de l’utilisation d’anciens pilotes ODBC ou lors de l’utilisation du pilote 3.7 pour se connecter à SQL Server 6.5 ou version antérieure. En outre, si vous stockez vos données dans des colonnes Unicode (NCHAR/NVARCHAR/NTEXT), la conversion ne sera pas un problème.

Pour plus d’informations sur la façon dont les données caractère sont représentées dans SQL Server 2005, consultez Données de caractères représentées de manière incorrecte lorsque la page de codes de l’ordinateur client diffère de la page de codes de la base de données dans SQL Server 2005.