迁移现有应用程序以接受 Unicode答案

【问题标题】：Migrating an Existing Application to accept Unicode迁移现有应用程序以接受 Unicode
【发布时间】：2010-09-10 01:01:42
【问题描述】：

我们正在将我们的应用程序升级到完全兼容 Unicode，因为我们最近获得了开箱即用的 Delphi 2009。我正在寻找任何有升级应用程序以接受 Unicode 字符的经验的人。具体回答以下任何问题。

我们需要将 VarChars 更改为 NVarchar，将 Char 更改为 NChar。这里有什么陷阱吗？
我们需要更新所有 sql 语句以在任何 sql 字符串前面包含 N。所以 Update tbl_Customer set Name = 'Smith' 必须变成 Update tbl_Customer set Name = N'Smith' 。对于某些字段，有什么方法可以默认此设置。这似乎很不寻常。
是否可以在 SQLServer 中设置任何默认值以简化此操作？

ps 我们还需要升级我们的 Oracle 代码

【问题讨论】：

标签： sql-server oracle delphi unicode migration

【解决方案1】：

Oracle 不要求您使用 nvarchar 来存储 Unicode 字符串——服务器可以配置为以 UTF-8 格式存储 varchar2。如果你之前只支持 ASCII，它应该是透明的。这应该可以避免对' 到N' 的所有应用程序端搜索和替换。

至于 Damien 的观点：它现在可能对您没有帮助，但您确实应该优先考虑摆脱非参数化查询。从维护、性能和安全的角度来看，它们只会拖累您的系统。

【讨论】：

【解决方案2】：

对于 SQL Server，显而易见的是 nchar/nvarchar 的限制是其对应的 char/varchar 的一半（除非您将所有 > 4000 的内容迁移到 nvarchar(max)）

【讨论】：

【解决方案3】：

达米安

我不确定您的回答是否有用。我们有一个庞大的 700,000 行编译代码库，这些代码库是在过去十年中编写的，其中包含大量的 sql 查询。大多数都标准化为几个功能，这些功能是数据库上大多数更新的基础。这些可以很简单地更新。但是，我们还需要检查 CustomerName = '%s' 的每个 where 子句，现在应该是 CustomerName = N'%s'

这是一个真正的问题，需要一个真正的答案。

【讨论】：