您正在看的SQLserver教程是:Microsoft SQL Server 2000 的國際化功能(3)。
這是理想的配置類型。通過在整個過程中以 Unicode 形式保存數據，您可以確保最佳的性能並防止檢索到的數據被毀壞。ADO 和 OLE DB 就屬於這種情況。
在這種配置中，您可能不會遇到數據存儲方面的問題，但是在將數據傳送到客戶端並使用這些數據時，明顯會有很大的限制。客戶端代碼頁必須用於在某一時刻轉換 Unicode 數據。
在數據層上的示例就是您從正在使用 DB-Library 的計算機連接到 SQL Server 2000 數據庫的時刻。DB-Library 是允許 C 應用程序訪問 SQL Server 的調用級別接口。自 SQL Server 6.5 以來，DB-Library 尚未進行重要的升級。對於我們來說，這將明顯地說明任何使用 DB-Library 的客戶端所面臨的限制。數據可以僅基於一個代碼頁，即系統的默認 OEM 代碼頁。您還可以選擇區域設置信息是否基於客戶端系統的區域設置。如以下圖解（圖 10）所示，在 SQL Server 客戶端網絡實用程序的“DB-Library 選項”選項卡中，您可以在兩個選項之間選擇 DB-Library 轉換信息的方式。在默認情況下，這兩個選項都會被選中。
www.iTbulo .comc3iWkZh
圖 10：默認的 DB-Library 選項
由於無法處理其他代碼頁上的數據，所以只有當數據層處於只需要處理 SQL Server 中數據子集的遺留系統中時，DB-Library 才真正具有意義。雖然確實有了解決的技術，已經使用它的開發人員不需要重寫其應用程序，但是如果需要支持多種語言數據，重寫仍可能是值得考慮的。
非 Unicode 客戶端的另一示例是不支持 Unicode 的程序，如 Microsoft Access 97。當 Access 數據庫可以連接到 SQL Server 2000 數據庫時，存在一些您應該知道的限制。例如，當您從美國英語的計算機連接到具有日語表名的數據庫時，就可能會看到一個表名已轉換為問號的對話框。以下圖解（圖 11）顯示了這種對話框的示例。
www.iTbulo .comc3iWkZh
圖 11：Access 97 中表名轉換為問號的圖解
此問題的原因是很容易理解的：Access 97 使用的是版本低於 3.7 的 ODBC，所以數據使用默認系統代碼頁從 Unicode 轉換為 ANSI。即使您安裝了 ODBC 的更高版本，Access 97 中的 Jet 3.5 仍將執行相同的轉換。由於日語字符不在美國英語計算機的代碼頁 1252 上，所以將它們替換為問號。
不可能與這些表建立連接。連接嘗試將導致圖 12 中所示的錯誤消息。
www.iTbulo .comc3iWkZh
圖 12：Microsoft Access 錯誤消息
這也很容易理解。數據一旦轉換為錯誤的代碼頁並由問號替換，將沒有辦法使其恢復。這將使 Jet 和 ODBC 直接嘗試連接到名為 dbo.???? 的表。因為該表不存在，此嘗試顯然會失敗。對於不在該代碼頁中的所有數據，也會出現這種情況。
類似的問題也將在表本身的數據中出現。例如，在一個包含朝鮮語數據的表中，您將看到非 Unicode 客戶端（如 Access）提供的數據顯示為問號。圖 13 中對此進行了說明。
www.iTbulo .comc3iWkZh
圖 13：非 Unicode 客戶端數據庫中問號的示例
在下面所有三種客戶端（即 DB-Library、ODBC 和 Jet 3.5）中，只理解如何將 Unicode 轉換為默認的系統代碼頁，而不理解 Unicode 的組件將不能處理這種多種語言數據。這種客戶端只能使用其默認系統代碼頁上可包含的數據。
對於多種語言數據而言，這不是理想的配置，因為您將無法在服務器上保存這種數據。但是，您至少可以確保數據會正確顯示。該配置具有前面情況中提到的所有限制，但不會因轉換無效而毀壞已接收的數據。示例之一就是 SQL Server 2000 數據庫將鏈接的服務器定義為 SQL Server 6.5 數據庫。從運行 SQL Server 6.5 的服務器接收的所有信息都將是有效的，但不要嘗試插入不在代碼頁上的數據。
