Вы символьных данных от клиента к серверу не удается правильно преобразовать с помощью драйвера ODBC для SQL Server, если кодовая страница клиента совпадает с кодовой страницы сервера

Переводы статьи Переводы статьи
Код статьи: 234748 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

Проблема

При использовании компонентов MDAC 2.1 или более поздней версии драйвера ODBC для SQL Server (версии 3.70.0623 или более поздней версии) или поставщик OLEDB (версии 7.01.0623 или более поздней версии), в некоторых случаях могут возникнуть преобразование символьных данных из кодовой страницы клиента в кодовую страницу сервера, даже если Autotranslation отключено для подключения.

Причина

Autotranslation не только механизмом, который может привести к преобразование кодовых страниц. Драйвер ODBC для SQL Server 7.0 и поставщик OLEDB вводить новое поведение при подключении к MSDE 1.0, SQL Server 7.0 или более поздней версии. Все инструкции SQL, которые отправляются в виде событий языка, преобразуются в Юникод на стороне клиента перед отправкой на сервер. Конечный результат аналогичен Autotranslation все данные, проходящие от клиента к серверу через события языка, независимо от текущей настройки Autotranslation для подключения. Это будет не вводить затруднений, за исключением при попытке сохранения-преобразовать символьные данные из кодовой страницы, отличные от кодовой страницы SQL Server.

Временное решение

Не следует хранить данные X код страницы в кодовой странице Y SQL Server (например, код страницы 950 данных на сервере код страницы 1252). При этом в некоторых случаях в предыдущих версиях SQL Server, она всегда была не поддерживается. К 1252 SQL Server но любое 1252 символ не является допустимым символьных данных. Символьные данные не в Юникоде с другой кодовой страницы не будут правильно упорядочены и из двух байтов данных (DBCS), SQL Server не распознает символ границы правильно. Это может вызвать серьезные проблемы, такие как проблемы, описанной в следующей статье Microsoft Knowledge Base:
155723INF: Усечение строки DBCS SQL Server
Лучший выбор для кодовой страницы SQL Server используется кодовая страница для клиентов, которые будут иметь доступ к серверу.

Сервер и клиент может иметь различные кодовые страницы, но необходимо убедиться, что Autotranslation включена на клиентском компьютере, таким образом, чтобы получить правильный перевод данных и кодовой странице сервера во всех случаях.

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

Если ситуации требуется хранить данные на странице X кода в кодовой странице Y SQL Server, существуют только два способа сделать это надежно.
  • Хранение данных в столбцах бинарных столбцов (BINARY и VARBINARY и IMAGE).
  • Напишите приложение на использование удаленных вызовов процедур (RPC) для всех инструкций SQL, которые работают с символьными данными. Данные, передаваемые через RPC события не затрагивает данное преобразование. Обратите внимание, что ничего не на уровне источника данных, которые можно выполнить, чтобы изменить тип событий, отправляемых или драйвера. Ли команда отправляется в качестве языка или RPC событий полностью зависит API и синтаксис выбранного программистом при записи приложения.

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

Autotranslation (то есть “ выполнять перевод символьных данных"флажки в новых приложениях ODBC) преобразует символьные данные из кодовой страницы клиента в кодовой странице сервера перед отправкой данных на сервере, использование Юникода в качестве носителя перевода. Тем не менее также 3.7 драйвера ODBC для SQL Server преобразует все инструкции SQL, отсылаются в виде событий языка Юникода перед их размещения на уровне подключения, который действует подобно Autotranslation, но не управляется параметром Autotranslation. В отличие от данных на сервере коды символов, данные, проходящие с сервера в отношении клиентов флаг Autotranslation; Если Autotranslation выключен данных поступает в клиентское приложение с одного и того же символа. Аналогичным образом преобразования данных для клиент сервер RPC события могут быть отключены, отключив Autotranslation. Простой сценарий, который демонстрирует, как это влияет на события языка выглядит следующим образом. В данном примере была запущена с помощью анализатора запросов на подключение к серверу страницы 437 код клиента 1252 страницы кода:
-- 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-строка преобразуются в Юникод до их отправки серверу, чтобы сервер смог преобразовать его в соответствующий знак для хранения данных в кодовой странице 437.
  • При запуске клиентаSelectдля получения данных, который только что был сохранен знак 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 произошло), но оно было влияние на данные, полученные от сервера. Note that when theSelectstatement is run this time (with Autotranslation on), the yen symbols display correctly in the code page 1252 application because they have been translated from character code 157 back to character code 165 by the Autotranslation mechanism.

You will see this behavior (conversion of language events to Unicode on the client) when using any SQL Server ODBC driver version 3.70 or later and connecting to SQL Server 7.0 or later. It will not occur when using older ODBC drivers, or when using the 3.7 driver to connect to SQL Server 6.5 or earlier. In addition, if you are storing your data in Unicode columns (NCHAR/NVARCHAR/NTEXT) the conversion will not be an issue.
For more information about how character data is represented in SQL Server 2005, click the following article number to view the article in the Microsoft Knowledge Base:
904803Character data is represented incorrectly when the code page of the client computer differs from the code page of the database in SQL Server 2005

Свойства

Код статьи: 234748 - Последний отзыв: 17 ноября 2010 г. - Revision: 2.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • 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
Ключевые слова: 
kbprb kbmt KB234748 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:234748

Отправить отзыв

 

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