Не може да превежда правилно знак данни от клиент към сървър чрез SQL Server ODBC драйвер, ако клиентът кодова страница се различава от сървъра кодова страница


Симптоми


Когато използвате MDAC 2.1 или по-нова версия на SQL Server ODBC драйвер (версия 3.70.0623 или по-късно) или доставчика OLEDB (версия 7.01.0623 или по-късно), при някои обстоятелства възникват превод на знак данни от клиента кодова кодова таблица сървър, дори когато Autotranslation е забранено за връзката.

Причина


Autotranslation не е единственият механизъм, който може да доведе до код за конвертиране на страница. SQL Server 7.0 ODBC драйвер и доставчика OLEDB въведе нови поведение при свързване на MSDE 1.0, SQL Server 7.0 или по-нови версии на един. SQL всички декларации, изпратени като език събитие се конвертират в Unicode на клиента преди изпращането на сървъра. Крайната цел на това е подобен на Autotranslation на всички данни, произтичащи от клиента към сървъра чрез език събитие, независимо от текущата Autotranslation настройките за връзка. Това няма да въвежда трудности с изключение при опит за съхраняване на данни не са преведени знак от кодова освен кодова таблица на SQL Server.

Заобикаляне на проблема


Код на страница X данни не се съхранява в кодова Y SQL Server (например код страница 950 данни в сървъра код 1252). Въпреки това е възможно в някои случаи с предишни версии на SQL Server, той е неподдържан. 1252 SQL Server нищо, но 1252 знак не е валиден знак данни. Не-Unicode знаци от друга кодова страница ще да подредите правилно и при две байта (DBCS) данни, SQL Server няма да разпознава знаци граници правилно. Това може да предизвика сериозни проблеми, като например проблем, описан в следната статия в базата знания на Microsoft:
155723 INF: отрязване на SQL Server на DBCS низ

Най-добрият избор за кодова таблица на SQL Server е кодова таблица на клиентите, които ще има достъп до сървъра.

Сървърът и клиентът може да имат различни кодови страници, но трябва да сте сигурни, че Autotranslation е разрешена на клиента, така че да получите точен превод на данни от сървъра кодова страница и във всички случаи.

Ако вашият сървър трябва да съхранява данни от множество кодови страници, поддържани решение е да съхранява данните в колони Unicode (NCHAR/NVARCHAR/NTEXT).

Ако вашата ситуация изисква да съхранявате код страница X данни през кодова Y SQL Server, има само два начина да направите това надеждно:
  • Данните се съхраняват в двоични колони (ДВОИЧНА/VARBINARY/ИЗОБРАЖЕНИЕ) колони.
  • Напишете вашето приложение да използва отдалечени процедури (RPC) за всички SQL команди, които разглеждат знак данни. При това преобразуване няма данни, изпратени през RPC събитие. Обърнете внимание, че няма драйвер или DSN ниво, които можете да направите, за да промените типа на събития се изпраща. Дали изпраща като език или RPC събитие зависи изцяло от API и синтаксис, избран от програма, когато приложението е записан.

Допълнителна информация


Autotranslation (, "Изпълнява превод знак данни" квадратчета в по-нови приложения, ODBC) преобразува знак данни от клиента кодова кодова таблица сървър преди изпращане на данните на сървъра, като Unicode превод среда. Обаче 3.7 SQL Server ODBC драйвер и преобразува всички SQL отчети, изпратени като език събитие в Unicode преди поставянето им в мрежа, която има ефект, който наподобява Autotranslation, но не се регулира от Autotranslation настройката. За разлика от това знак данни, произтичащи от сървъра към клиента спазват Autotranslation флаг; Ако е изключена Autotranslation данните пристигне клиентът приложение със същия знак кодове като данни е на сървъра. Също така превод на данни за събития, RPC клиент сървър може да бъде деактивиран чрез изключване Autotranslation. Следва прост скрипт, който показва как това засяга езиковите събития. Този пример е стартирана от анализатор на заявки на код страница 1252 клиент с код 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)
Обърнете внимание на следното за предишния пример:
  • Въпреки че Autotranslation е оставен по време на тази папка, кода 165 (йени през кодова страница 1252) е преобразувана в 157 (йени през кодова 437). Това е защото ODBC драйвер преобразува SQL низ в Unicode преди да го изпратите сървъра, така че сървърът е в състояние да го превърнете в съответния знак за съхранение в кодова 437.
  • Когато клиентът се проведе ИЗБОР за извличане на данните, които са съхранени само, знакът 157 достигнал не са преведени до клиента (157 се показва като кутия "" на страница 1252 клиентски код). Това е защото преобразуването в тази статия се отнася само за данни, изпратени от клиента към сървъра, а не от сървъра към клиента. Данните не е преведена, защото Autotranslation настройка е изключен.

-- 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)
В този случай включите Autotranslation не се отразиха на превода от клиента към сървъра (т. е същата правилния превод от код 165 на код 157 стана), но той има влияние върху данни от сървъра. Обърнете внимание, че когато ИЗБЕРЕТЕ изречението е това време (с Autotranslation на), йени символи се показват правилно в приложението код страница 1252 понеже те са преведени от код 157 обратно към код 165 Autotranslation механизъм.

Ще видите това поведение (преобразуване на език събития в Unicode на клиента), когато използвате всички SQL Server ODBC драйвер версия 3.70 или по-нова и свързване на SQL Server 7.0 или по-късно. Тя няма да се случи при използване на по-стари драйвери за ODBC, или когато използвате 3.7 драйвер за свързване към SQL Server 6.5 или по-рано. Освен това ако съхранявате вашите данни в колони Unicode (NCHAR/NVARCHAR/NTEXT) преобразуването няма проблем.
За повече информация как се представят характер данни в SQL Server 2005 щракнете върху следния номер на статия в базата знания на Microsoft:

904803 знак данни представлява неправилно когато кодова таблица на клиентския компютър се различава от кодова таблица на базата данни в SQL Server 2005