目前,我们的数据库使用Win1252作为唯一的字符编码。我们将很快在数据库表中支持Unicode,这意味着我们必须为四个数据库和大约80个Delphi应用程序执行此迁移,这些应用程序在24/7环境中内部运行。是否有针对Delphi应用程序的数据库迁移到UTF-8(或UNICODE_FSS)的建议?下面列出了一些问题。非常感谢您的回答!
更新:来自InterBase论坛帖子:Unicode Databases in InterBase - Really?(它不是我的一个帖子,但它表明InterBase XE中仍存在一些问题)。
以下是我提交的一些报告: QC#92867 - 字符串字段为空 仅来自View的视图 包括一个联盟,并在使用时 ClientDataSet的。这被发现是 我的一些报告中缺少数据, 不再有效。
QC#91494 - IB字符列数据 字符字段(例如:Char(1))是 检索时用空白填充 通过存储过程。测试失败 - 例如:如果Active =“Y”。我大量使用表单存储过程 这些都行不通。
QC#91355 - IBSqlMonitor失败。该 IBSqlMonitor的输出有点 使这个工具无用的乱码。 (所以, 即使我的铲子坏了!)
未报告 - 中的持久字段 TWIDEString的TClientDataSet失败。
其他相关的QC条目:
QC#94455 SQL Unicode字符类型失败(InterBase XE)
答案 0 :(得分:1)
答案 1 :(得分:1)
问题:空字符串字段上的UPDATE不再找到记录。如果UTF8字符字段为空,则DataSetProvider会为更新操作生成错误的SELECT。
症状:未找到或编辑其他用户的消息'
解决方案:升级到Delphi 2010 Update 4或使用QC中描述的解决方法
答案 2 :(得分:0)
问题:CHAR字段不再有效,必须用VARCHAR替换。
症状:对现在使用UTF8并从WIN1252导入的具有ASCII值的列的SELECT查询不再返回任何值。也许这是我应该在QC中报告的错误。
解决方案:使用CHAR(
VARCHAR(
的所有出现次数
答案 3 :(得分:0)
问题:持久字符串字段需要Size属性,该属性是字段的逻辑大小乘以4(另请参阅:Is it possible to tweak TStringField to work like TWideStringField in Delphi?)
症状:访问违规
解决方案:删除持久字段并再次添加以更新Size属性。 (副作用:DisplayWidth也会增加尺寸,导致UI出现问题)
答案 4 :(得分:0)
问题:由于大小限制,带字符串参数的UDF(用户定义函数)可能会中断。
症状:
Dynamic SQL Error.
SQL error code = -204.
Data type unknown.
Implementation limit exceeded.
COLUMN DSQL internal.
这个UDF:
DECLARE EXTERNAL FUNCTION STRLEN
CSTRING(32767)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'IB_UDF_strlen' MODULE_NAME 'ib_udf';
解决方案:修复声明中的UDF参数。
答案 5 :(得分:0)
问题:dbExpress在内部使用WideString作为数据类型,因此读取/设置字段和参数的所有现有.AsString
调用将不再起作用
症状:无法正确存储/读取特殊字符
解决方案:将所有出现的.AsString替换为.AsWideString,但要注意不要更改字段或参数上未调用AsString方法的位置。
答案 6 :(得分:0)
问题:dbExpress需要WIN1252字段的TStringField对象。对于UTF8数据库字段,dbExpress需要TWideStringField对象。
症状:错误消息'预期:找到WideString:字符串'
解决方案:用TWideStringField替换TStringField的所有出现。这要求所有表单文件(dfm)都是文本,而不是二进制文件。修改后的表单和数据模块不会向后兼容。
答案 7 :(得分:0)
问题:导出WIN1252数据库的元数据和表数据将创建CP1252编码文件,但是对于导入,需要UTF8文件(使用IBExpert测试)
症状:脚本中的错误导入InterBase
解决方案:使用iconv将脚本文件转换为UTF8