【问题标题】:Firebird 2.5 query returns COLLATION UTF8_CI_AI_NUMERIC_SORT for CHARACTER SET UTF8 is not installedFirebird 2.5 查询返回 COLLATION UTF8_CI_AI_NUMERIC_SORT for CHARACTER SET UTF8 is not installed
【发布时间】:2021-08-30 16:43:04
【问题描述】:

我有一个旧的源数据库,其中显然创建了自定义排序规则 UTF8_CI_AI_NUMERIC_SORT。我通过图像jacobalberty/firebird:2.5-ss 在 docker 上运行它。最初数据库是在 Windows 机器上创建的。

当我尝试对使用此排序规则的表进行查询时,我收到错误:

SQL> select * from "InvoiceService";
Statement failed, SQLSTATE = 22021
COLLATION UTF8_CI_AI_NUMERIC_SORT for CHARACTER SET UTF8 is not installed

显示排序规则返回以下内容:

SQL> show collations;
UTF8_CI_AI_NUMERIC_SORT, CHARACTER SET UTF8, FROM EXTERNAL ('UNICODE'), CASE INSENSITIVE, ACCENT INSENSITIVE, 'NUMERIC-SORT=1'

我尝试了以下修复:

  1. fbintl.conf添加条目:
<charset UTF8>
    intl_module fbintl
    collation   UTF8_CI_AI_NUMERIC_SORT
</charset>

然后运行sp_register_character_set("UTF8", 4) 过程,并收到关于重复排序规则的错误(因为 UTF8_CI_AI_NUMERIC_SORT 已在数据库中定义)。

  1. 删除排序规则
SQL> drop collation UTF8_CI_AI_NUMERIC_SORT;
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-Collation UTF8_CI_AI_NUMERIC_SORT is used in table InvoiceService (field name NAME) and cannot be dropped
  1. 添加将使用不同排序规则的新列,但甚至无法添加:
SQL> ALTER TABLE "InvoiceService" ADD NAME2 VARCHAR(600) CHARACTER SET UTF8;
Statement failed, SQLSTATE = 22021
unsuccessful metadata update
-InvoiceService
-COLLATION UTF8_CI_AI_NUMERIC_SORT for CHARACTER SET UTF8 is not installed
  1. 使用gbak 仅恢复元数据、修复架构然后仅插入数据,但gbak 不支持仅恢复数据

...

我现在没有主意了。我还能尝试什么?

【问题讨论】:

  • 尝试注册 UTF8 字符集是没有意义的,因为它已经存在于您的数据库中。 IIRC,UTF8 排序规则不需要在 fbintl.conf 中注册,因为它们是从 ICU 库自动应用的。而且您的定义不会以任何方式起作用,因为这将要求 ICU 具有具有该确切名称的排序规则,而它只是在您的数据库中赋予它的名称。我的第一个猜测是图像中的 ICU 库存在问题。我会尝试一些事情,看看我是否能找出这里发生了什么。
  • 也可以在firebird-support Google Group 上提问。
  • 谢谢马克。我在想问题可能是在一台服务器上创建了排序规则,然后复制了数据库文件,然后我在另一台机器上/在 Docker 中使用它。所以目前的机器无法知道这个排序规则是什么。但是有没有办法以某种方式至少获取此列的原始数据(以字节为单位)?
  • Source DB 实际上是在 Windows 上创建的。
  • 几年以来,在大多数情况下它似乎都可以工作,但如果您有使用排序规则的索引,那么备份和恢复是必要的,因此使用目标上安装的 ICU 版本重建索引系统。可能还有其他可能的问题,虽然我现在想不出来。

标签: utf-8 firebird database-restore firebird2.5


【解决方案1】:

所以,我终于设法解决了这个问题。我所做的是创建一个数据库备份

gbak -v -t -user SYSDBA /path/to/source.fdb /path/to/backup.fbk

然后使用 3.0 版本的 Docker 镜像和 Firebird DB (jacobalberty/firebird:3.0) 并从备份中恢复

gbak -create /path/to/backup.fbk /path/to/restored3.fdb

请注意,不切换 Docker 映像的相同备份-恢复过程不起作用。

我不需要做任何其他事情。 SHOW COLLATIONS; 的输出只有细微的差别:

// originally:
UTF8_CI_AI_NUMERIC_SORT, CHARACTER SET UTF8, FROM EXTERNAL ('UNICODE'), CASE INSENSITIVE, ACCENT INSENSITIVE, 'NUMERIC-SORT=1'

// restored DB
UTF8_CI_AI_NUMERIC_SORT, CHARACTER SET UTF8, FROM EXTERNAL ('UNICODE'), CASE INSENSITIVE, ACCENT INSENSITIVE, 'COLL-VERSION=58.0.6.50;NUMERIC-SORT=1'

【讨论】:

  • 如果去 Firebird 3.0 修复它,那么我猜 Firebird 2.5 图像中的 ICU 有问题。
  • Firebird 2.5 中的整个 INTL 模块有问题。它不应该用于像这样的高级事物。
  • 附带说明,恢复的数据库可以在 Firebird 2.5 上正常工作
猜你喜欢
  • 2023-03-16
  • 1970-01-01
  • 2021-01-19
  • 2014-11-09
  • 2020-03-31
  • 2013-05-17
  • 2010-12-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多