Программирование на стороне клиента и сервера

В этом подразделе описано, как сохранить целостность символьных данных, когда база данных не сохраняет символьные данные при помощи типов данных Юникод и когда клиентские приложения, взаимодействующие с данными, не поддерживают Юникод. В этой ситуации кодовые страницы хранилища данных и кодовые страницы клиентского приложения должны быть одинаковыми. Если эти кодовые страницы различны, то при преобразовании между клиентом и сервером может возникнуть потеря некоторых символов. Не поддерживается отключение функции AutoTranslate драйвера SQL Server ODBC для вставки данных с сервера, определенных другой кодовой страницей, из сервера. Хотя, даже если AutoTranslate отключена, это не предотвращает преобразование кодовых страниц для событий языка SQL. В результате, если кодовые страницы клиента и базы данных не совпадают, то преобразование кодовых страниц будет в основном применяться к отправляемым и принимаемым сервером символьным строкам отличного от Юникода типа. По возможности следует избегать такой ситуации. Наилучшим для сервера с определенной кодовой страницей является связь с клиентами, использующими ту же кодовую страницу. Вторым приемлемым решением является использование другой кодовой страницы, имеющей практически такую же кодировку. Например, кодовая страница 1252 (Latin1) и кодовая страница 850 (Multilingual Latin1) обладают практически одинаковыми кодировками, поэтому большинство символов в этих двух кодовых страницах могут быть преобразованы из одной страницы в другую без потери данных. Если приходится связываться с клиентами при помощи различных кодовых страниц, то правильным решением является сохранение данных в столбцах Юникод. Если ни один из этих вариантов неосуществим, то альтернативой является хранение данных в двоичных столбцах с типами данных binary, varbinary или varbinary(max). Однако двоичные данные могут сортироваться и сравниваться только двоичным способом. Это делает их менее гибкими, чем символьные данные.