管理用戶端/伺服器字碼頁之間的資料轉換
此主題描述在資料庫未使用 Unicode 資料類型儲存字元資料，且與資料互動的用戶端應用程式也不具 Unicode 感知時，應如何保有字元資料的完整性。在此情況下，資料儲存的字碼頁與用戶端應用程式的字碼頁應相同。如果這些字碼頁不同，則在用戶端與伺服器之間執行轉換時，可能會遺失部分字元。
您無法停用 SQL Server ODBC 驅動程式的 AutoTranslate 功能，以插入與伺服器不同之字碼頁所定義的資料。此外，即使停用 AutoTranslate，仍無法防止 SQL 語言事件的字碼頁翻譯。因此，如果用戶端與資料庫的字碼頁不相符，往返於伺服器的任何非 Unicode 字元字串在一般情況下都會執行字碼頁翻譯。
請盡可能避免這種情況。對有字碼頁限制的伺服器而言，最好的方式就是只與使用相同字碼頁的用戶端通訊。其次，可以選擇使用其字元集幾乎相同的其他字碼頁。例如，字碼頁 1252 (Latin1) 與字碼頁 850 (多國語言 Latin1) 可儲存的字元集幾乎完全相同，因此這兩種字碼頁中的字元大多可在字碼頁之間轉換，而不會遺失資料。
如果您必須與使用不同字碼頁的用戶端通訊，可行的方式是將資料儲存在 Unicode 資料行中。如果上述方式都不可行，還有一個辦法是使用 binary、varbinary 或 varbinary(max) 資料類型，將資料儲存在二進位資料行中。但二進位資料只能以二進位順序進行排序與比較。與字元資料相比，就顯得比較沒有彈性。