Managing Data Conversion Between Client/Server Code Pages
W tym temacie opisano sposób w celu zachowania spójności danych znakowych, gdy baza danych nie przechowuje danych znakowych, za pomocą typy danych standardu Unicode i aplikacji po stronie klient, interaktywnie pracować z danymi są również nie Unicode wiedzieć.W takim przypadku strona kodowa użytkownika przechowywania danych i strona kodowa klient aplikacji powinny być takie same.Jeśli te strony kodowe są różne, konwersji, który występuje między klient a serwerem może spowodować utratę niektórych znaków.
Wyłączenie funkcji AutoTranslate SQL Server Sterownik ODBC, aby wstawić dane zdefiniowane przez inną strona kodowa z serwera nie jest obsługiwana. Ponadto nawet po wyłączeniu AutoTranslate go nie zapobiega kod strona translacji zdarzeń języka SQL.Wynik jest o tym, że jeśli stron kodowych klient i baza danych nie pasują do siebie, tłumaczenia kodu strona będą zwykle stosowane dowolnego ciąg znaków nie obsługujących kodu Unicode, wysyłanych do lub z serwera.
Jeśli jest to możliwe, należy unikać tej sytuacji.Najlepszym rozwiązaniem w przypadku kodu specyficzne dla strony serwera jest komunikowanie się tylko z klientami, przy użyciu tej samej strona kodowa.Wybór najlepszych drugi polega na użyciu inną strona kodowa, która jest prawie tym samym zestaw znaków.Na przykład, strona kodowa 1252 (Latin1) i strony kodowej 850 (wielojęzyczny Latin1) mogą przechowywać prawie taki sam zestaw znaków, dzięki czemu większość znaków w tych dwóch kod stron mogą być konwertowane na inny bez utraty danych z jednej stronie kodowej.
Jeśli użytkownik musi komunikować się z klientami przy użyciu różne strony kodowe, obsługiwane rozwiązaniem jest przechowywanie danych w kolumnach Unicode.Jeśli jeden z tych opcji nie jest możliwe, inne alternatywą jest przechowywanie danych w kolumnach binarnego przy użyciu binary, varbinary, lub varbinary(max) typy danych. Jednak dane binarne tylko można sortować i w kolejności binarnych w porównaniu.Dzięki temu mniej elastyczne niż danych znakowych.