Vous ne peut pas correctement convertir les données caractère à partir d'un client à un serveur en utilisant le pilote ODBC SQL Server si la page de codes client diffère de la page de codes de serveur

Traductions disponibles Traductions disponibles
Numéro d'article: 234748 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Symptômes

Lorsque vous utilisez le MDAC 2.1 ou version ultérieure du pilote ODBC SQL Server (version 3.70.0623 ou version ultérieure) ou du fournisseur OLEDB (version 7.01.0623 ou version ultérieure), dans certaines circonstances vous pouvez rencontrer conversion des données de caractères de la page de codes client vers la page de code serveur, même lorsque Autotranslation est désactivé pour la connexion.

Cause

Autotranslation n'est pas le seul mécanisme peut entraîner la conversion de page de codes. Le pilote ODBC SQL Server 7.0 et le fournisseur OLEDB présente un nouveau comportement lorsque vous vous connectez à MSDE 1.0, SQL Server 7.0 ou versions ultérieures de soit. Toutes les instructions SQL envoyées en tant qu'un événement de langue sont convertis en Unicode sur le client avant d'être envoyé au serveur. L'effet de fin de ce est similaire à une Autotranslation de toutes les données se déplaçant vers le serveur via un événement de langue, indépendamment du paramètre Autotranslation actuel de la connexion à partir du client. Cela présente pas les difficultés sauf lorsque tente de stocker les données caractère non traduit d'une page de code différente de page de codes SQL Server.

Contournement

Ne stockez pas de code page X données dans une page de code Y SQL Server (par exemple, code page 950 données sur un serveur code page 1252). Alors que cela était possible dans certains cas avec les versions précédentes de SQL Server, il a toujours été non pris en charge. Pour un serveur SQL 1252, tout sauf une 1252 caractère n'est données caractères valides pas. Données de caractères non-Unicode d'une autre page de codes ne seront pas triées correctement, et dans le cas de double octets (DBCS) données, SQL Server ne reconnaît pas les limites de caractères correctement. Cela peut entraîner significatives de problèmes, tels que le problème décrit dans l'article suivant dans la Base de connaissances Microsoft :
155723 Fichier INF: SQL Server troncature d'une chaîne de caractères DBCS
Le meilleur choix pour code page le serveur SQL est la page code des clients qui accéderont au serveur.

Le serveur et le client peuvent avoir différentes pages de codes, mais vous devez Vérifiez que Autotranslation est activée sur le client afin que traduction correcte des données et de page de codes ?s le serveur dans tous les cas.

Si votre serveur doit stocker des données à partir de plusieurs pages de code, la solution prise en charge est de stocker les données dans des colonnes Unicode (nchar/nvarchar/ntext).

Si votre situation requiert que vous stockiez les données de page X du code dans une page de codes Y SQL Server, il existe uniquement deux manières de faire fiable :
  • Stocker les données dans des colonnes colonnes binaire (Binary/varbinary/image).
  • Écrire 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 soumis à cette conversion. Notez qu'il existe rien au niveau DSN que vous pouvez faire pour modifier le type d'événements envoyé ou pilote. Si une commande est envoyée qu'une langue ou un événement RPC dépend entièrement les API et la syntaxe choisi par le programmeur lors de l'application est écrite.

Plus d'informations

Autotranslation (c'est-à-dire les ? effectuer la traduction des données de caractères » cases dans les applications ODBC plus récentes) convertit caractères données de la page de codes client dans la page de codes de serveur avant d'envoyer les données sur le serveur, en Unicode un support de traduction. Cependant, le pilote ODBC SQL Server 3.7 convertit également toutes les instructions SQL envoyées en tant qu'un événement de langue au format Unicode avant d'en les plaçant sur le réseau, ce qui a un effet qui est similaire à Autotranslation mais n'est pas déterminé par le paramètre Autotranslation. En revanche, caractères de données se déplaçant à partir du serveur à l'égard de clients l'indicateur Autotranslation ; Si Autotranslation est désactivée sur les données arrivent à l'application client avec le même caractère codes que les données avait sur le serveur. De même, conversion des données d'événements RPC client-serveur peut être désactivée en désactivant Autotranslation. Un script simple qui illustre comment ce problème affecte les événements de langue suit. Cet exemple a été exécuté à partir de l'Analyseur de requêtes sur un client page 1252 code connexion à un serveur page 437 code :
-- 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)
Notez les opérations suivantes sur l'exemple précédent :
  • Même si Autotranslation était désactivé pendant ce traitement par lots, le code du caractère 165 (yen dans la page de codes 1252) a été converti en 157 (yen dans la page de codes 437). C'est parce que le pilote ODBC converti la chaîne SQL au format Unicode avant d'envoyer le le serveur, pour le serveur a pu convertir le caractère approprié pour le stockage dans la page de codes 437.
  • Lorsque le client exécuté un SELECT pour récupérer les données uniquement a été stockées, le caractère 157 arrivé non traduit sur le client (157 affiche des qu'une zone «  » sur un client page 1252 code). Cela est dû au fait que la conversion abordée dans cet article s'applique uniquement à des données renvoyées du client pour le serveur et non le serveur pour le client. Les données a été traduites pas parce que le paramètre Autotranslation 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, activer la Autotranslation n'avait aucun effet sur la conversion à partir du client au serveur est (c'est-à-dire, la traduction correcte même à partir du code caractère 165 au code de caractère 157 devenu), mais il un effet sur les données récupérées à partir du serveur. Notez que lorsque l'instruction SELECT est exécutée cette fois (avec Autotranslation sur), les symboles du yen afficher correctement dans la code page 1252 application car ils ont été traduits du code de caractère 157 au code de caractère 165 par le mécanisme Autotranslation.

Vous verrez ce problème (conversion d'événements de langue au format Unicode sur le client) lorsque l'aide de n'importe quel ODBC SQL Server version du pilote 3.70 ou version ultérieure et connexion à SQL Server 7.0 ou version ultérieure. Il ne se produit pas lorsque vous utilisez d'anciens pilotes ODBC ou lorsque vous utilisez le pilote 3.7 pour vous connecter à SQL Server 6.5 ou antérieures. En outre, si vous stockez vos données dans des colonnes Unicode (nchar/nvarchar/ntext) la conversion sera pas un problème.
Pour plus d'informations sur la représentation des données de caractères dans SQL Server 2005, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
904803 Données de caractères sont représentées incorrectement lors de la page de code de l'ordinateur client est différente de la page de code de la base de données dans SQL Server 2005

Propriétés

Numéro d'article: 234748 - Dernière mise à jour: jeudi 22 février 2007 - Version: 4.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 7.0 Standard
  • Microsoft Open Database Connectivity 3.7
  • Microsoft Data Engine 1.0
  • Microsoft SQL Server 2000 Standard
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Mots-clés : 
kbmt kbprb KB234748 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 234748
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com