这是理想的配置类型。通过在整个过程中以 Unicode 形式保存数据，您可以确保最佳的性能并防止检索到的数据被毁坏。ADO 和 OLE DB 就属于这种情况。
Unicode 服务器和一个或多个非 Unicode 客户端在这种配置中，您可能不会遇到数据存储方面的问题，但是在将数据传送到客户端并使用这些数据时，明显会有很大的限制。客户端代码页必须用于在某一时刻转换 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 的组件将不能处理这种多种语言数据。这种客户端只能使用其默认系统代码页上可包含的数据。
非 Unicode 服务器和 Unicode 客户端对于多种语言数据而言，这不是理想的配置，因为您将无法在服务器上保存这种数据。但是，您至少可以确保数据会正确显示。该配置具有前面情况中提到的所有限制，但不会因转换无效而毁坏已接收的数据。示例之一就是 SQL Server 2000 数据库将链接的服务器定义为 SQL Server 6.5 数据库。从运行 SQL Server 6.5 的服务器接收的所有信息都将是有效的，但不要尝试插入不在代码页上的数据。
非 Unicode 服务器和客户端这是限制最多的配置，因为无论什么时候，您基本上只能使用一个代码页。
从 SQL Server 早期版本进行的多种语言数据转换并非所有用户都有耐心等待使用 SQL Server 7.0 和 SQL Server 2000 中包含的 Unicode 功能来处理他们的多种语言数据。因此，有些用户已创建了自定义编码架构来存储这种数据。如果您考虑使用这种方法，那么您将需要使用大容量复制实用程序 (bcp) 将数据保存为二进制形式（意味着无数据转换），然后使用 -C 命令行参数将数据大批量复制到相应的代码页。有关 bcp 实用程序的详细信息，请参见本文稍后的使用 bcp 实用程序来处理多种语言数据。
使用 Access 2000 的新 ADP 格式Microsoft Access 2000 增添了一个新文件格式选项，它不是 Jet 数据库，而是 Access 数据项目 (ADP)。这些文件可以直接作为 SQL Server 的前端。
ADP 功能超出了本文讨论的范围，但要指出的两个重要问题是：
Access 2000 不支持 SQL Server 2000，除非安装了 SQL Server 2000 客户端工具。 在 Access 内 SQL Server 数据的所有入口点（窗体、数据访问页、表数据表视图和 ADO）中，Access 和 SQL Server 之间存在一个中间层，即 COM。它会影响日期/时间值、数字和货币值的输入，因为客户端（在这种情况下指 ADP 所在的计算机）的区域设置用于解释数据的含义。当您使用 Access 时，务必要记住这一点，因为 SQL Server 的规则在某些情况下限制并不多。有关详细信息，请参见本文稍后的处理 COM 的区域设置冲突。 用户界面中的多种语言数据尽管 SQL Server 主要是服务器，但它仍带有多种管理工具。这些工具已根据需要在 Server 2000 中进行了更新，以支持多种语言数据。
一般的 UI 更改（Unicode 支持）在处理当前默认代码页或服务器代码页上的表名时，SQL Server 企业管理器表现相当出色。在需要时，它还可以利用 Windows 中的一些字体链接技术来“借用”其他字体的字符，如以下图解（图 14）中所示。
www.iTbulo .comc3iWkZh
14： 字体链接技术示例
如上所示，字体链接无法完成全部工作。对于许多种语言（如亚美尼亚语、Sylfaen、格鲁吉亚和印地语），Windows 没有高级字体链接信息。另外，当某种语言使用在脚本中不常用的字符（如阿泽里语 － 斯拉夫语）时，除了少数字符可能不会显示外，字符串的大多数字符都将显示。
有三件有趣的事值得注意：
只要名称在字体中不受支持且字体链接无法实现，您将看不到毁坏的字符；相反，您将看到如上所示的对话框，它表示有无法显示的字符。 SQL Server 2000 客户端工具没有使用 Uniscribe 技术来呈现复杂的脚本，所以如果您使用的不是 Windows 2000，双向语言（如前面图解所示的希伯来语、意第绪语、阿拉伯语和波斯语）字符向后显示。但是，在 Windows 2000 和支持 BIDI 的平台上，这些字符将正确显示。其他复杂脚本的呈现问题（如泰语的断字）则会遇到同样的限制（即使不在 Windows 2000 上）。 SQL Server 企业管理器所用的“基本”字体是在计算机桌面显示设置中定义的，它不能被覆盖。 SQL 查询分析器的网格和 SQL 窗格中的多种语言信息在 SQL Server 企业管理器中，不能对字体进行更改；但是，在 SQL 查询分析器中，您可以在“选项”对话框中的“字体”选项卡中显式地更改用户界面多个部分的字体。
www.iTbulo .comc3iWkZh
图 15：“SQL Server 2000 查询分析器字体”对话框
由于字体链接似乎允许显示大多数字符串，所以进行这种更改的原因起初可能并不明显。但是，正确显示字符串要比简单地找到可表示字符的字体要费事得多。通常，字体选择是很重要的。因此，这种功能对于正确显示多种语言数据也相当重要。在字体链接看来无法工作的情况下，该功能将使您看到字符串，而不是对话框。
查询设计器中的格式问题在查询设计器的许多部分中，您可以在网格窗格中输入与计算机的默认区域设置匹配的信息，或者可以显式地使用 CONVERT 函数来处理采用任意格式的字符串。
在采用这种区域设置使用方法时，您应该明确以下一些的设计限制：
不支持长数据格式。 虽然可以选择使用美元符号 ($)，但不应在网格窗格中输入货币符号。无论怎样，从区域设置中检索到的货币符号都将在“结果”窗格中使用。 无论区域设置是什么，一元减号始终显示在左侧，且不带括号。因此，-1 应该显示为 -1，而不是 1- 、(1)，也不是可能在“区域选项”对话框中指定的任何有效变量。要在查询设计器中实现一定程度的全球性支持，这些限制是必需的，它们不会妨碍大多数使用特定于区域设置的数据的操作。
请注意：在“网格”窗格中输入的任何信息都将在“SQL” 窗格中转换为与区域设置无关的格式，这样，在标准德国计算机上输入的“03.09.65”将转换为 { ts ' 1965-09-03 00:00:00 }。所有直接输入“SQL”窗格的数据都应该是这种格式，否则，应包含一个明确 CONVERT 调用。
排序顺序“结果”窗格中数据的顺序不受“区域设置”的影响，而是由排序规则（请参见本文前面的 SQL