1

从 SQLA 中包含 86 列的表中选择所有列时，我总是得到错误Row size or Sort Key size overflow。避免此错误的唯一方法是减少 select 中的列数，但这是一种非常规的解决方案。必须有一种方法可以在一个选择语句中从该表中选择所有列。

赏金

我正在添加这个赏金，因为我不能再破解这个问题了。必须有一个解决方案。现在，我正在从包含 Unicode 列的表中进行选择。我假设这导致行大小超过容量。当我Session Character Set=UTF8从我的连接字符串中删除时，我得到The string contains an untranslatable character. 我正在使用 NET 数据提供程序 14.0.0.1。有没有办法增加尺寸？

更新

罗布，你永远不会停止留下深刻的印象！您建议使用 UTF16 有效。在我更新我的 ODBC 配置后，它甚至可以在 SQLA 中工作。我一直认为我的问题是我对 ASCII、拉丁文、UTF8 和 UTF16 缺乏了解。

我们还有一个包含所有拉丁列的 80 列的表，其中一些是 `varchar(1000)'。在 UTF8 和 UTF16 中从 SQLA 中进行选择时，我在 SQLA 中遇到相同的错误，但在我的 ODBC 配置中将我的字符集更新为 ASCII 或拉丁模式后，我可以从中进行选择。

Rob，你能提供关于这里发生的事情的见解吗？我的理论是，因为它在拉丁语集中，使用 UTF8 或 UTF16 会导致转换为更大的字节集，从而导致错误，尤其是对于varchar(1000)'s. 如果我使用拉丁语作为我的会话字符集，则不会进行任何转换，并且我会以本机编码获得字符串。至于有问题的问题，UTF8失败是因为编码不能“降级”吗？

根据请求，这里是相关表的 DDL：

CREATE MULTISET TABLE mydb.mytable ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT,
     DEFAULT MERGEBLOCKRATIO
     (
      FIELD1 VARCHAR(214) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      FIELD2 VARCHAR(30) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD3 VARCHAR(60) CHARACTER SET UNICODE CASESPECIFIC NOT NULL,
      FIELD4 VARCHAR(4000) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD5 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD6 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD7 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD8 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD9 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD10 VARCHAR(900) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD11 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD12 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD13 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC,
      FIELD14 VARCHAR(3600) CHARACTER SET UNICODE CASESPECIFIC)
PRIMARY INDEX ( FIELD1 );
4

1 回答 1

3

在没有看到您的表定义的情况下，您是否考虑过使用 UTF16 而不是 UTF8 SESSION CHARSET？

对您的错误消息进行的更多研究发现这篇文章表明 UTF16 可能使您能够返回 UTF8 否则不会返回的记录。

编辑：如果您从我上面共享的链接中回忆起，对于给定的 VARCHAR(n)，要存储的字节如下：

  • 拉丁语：n 字节
  • UTF8：n*3 字节
  • UTF16：n*2 字节

这意味着 UTF8 会话中的 VARCHAR(4000) UNICODE 字段应该需要 12KB。如果您必须始终如一地处理 UNICODE 数据，则将默认会话字符集保留或更改为 UTF16 可能对您有利。根据我的经验，我不必使用 UNICODE 数据，因此我无法告诉您更改字符集是否会为数据库中其他地方的 LATIN 数据引入什么陷阱。

希望这可以帮助。

于 2014-04-18T14:52:51.987 回答