Teradata SQLA：行大小或排序键大小溢出

当在SQLA中从包含86列的表中选择所有列时，我总是得到错误

行大小或排序键大小溢出

。避免此错误的唯一方法是减少select中的列数，但这是一种非常规的解决方案。必须有一种方法在一个select语句中选择此表中的所有列

赏金

我之所以增加这笔赏金，是因为我再也无法破解这个问题了。必须有一个解决办法。现在，我正在从一个包含Unicode列的表中进行选择。我假设这会导致行大小超过容量。当我从连接字符串中删除会话字符集=UTF8时，我得到的错误是

字符串包含一个不可翻译的字符

。我正在使用网络数据提供程序14.0.0.1。有没有办法增加尺寸

更新

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

我们还有一个80列的表，由所有拉丁列组成，其中一些是“varchar（1000）”。在UTF8和UTF16中选择SQLA时，我在SQLA中会遇到相同的错误，但在ODBC配置中将字符集更新为ASCII或拉丁模式后，我可以很好地进行选择

罗布，你能提供一些关于这里发生了什么的见解吗？我的理论是，因为它是在拉丁集合中，使用UTF8或UTF16会导致转换为更大的字节集合，从而导致错误，尤其是对于

varchar（1000）

。如果我使用拉丁语作为会话字符集，则不会进行任何转换，而是以其本机编码获取字符串。至于问题，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 );

---

在没有看到表定义的情况下，您是否考虑过对

会话字符集使用UTF16而不是UTF8

对错误消息的进一步研究发现，这表明UTF16可以让您返回UTF8无法返回的记录

编辑：
如果您还记得我在上面共享的链接，对于给定的VARCHAR（n），要存储的字节如下所示：


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

这意味着UTF8会话中的VARCHAR（4000）UNICODE字段需要12KB。如果您必须一致地处理UNICODE数据，那么将默认会话字符集保留或更改为UTF16可能会对您有利。根据我的经验，我不必使用UNICODE数据，因此我无法告诉您更改字符集是否会给数据库中其他位置的拉丁语数据带来什么陷阱

希望这有帮助。
您在BTEQ中尝试过相同的选择吗？是否有与此消息相关联的错误号？它在BTEQ脚本中不起作用。它在
***查询完成时成功执行。找到2行。返回了86列。
。但是，当我在我的测试.NET应用程序中运行完全相同的SQL时，我确实收到了
行大小或排序键大小溢出
错误。在SQLA中，您是否正在与.NET提供程序连接？如果是，请尝试ODBC。我认为您可能遇到了.Net提供商的限制。如果您使用的是TD 14，请尝试将TMODE更改为“TERA”。Sweet。更改为UTF16已经解决了这个问题，您可能已经让我找到了关于这个错误的另一个问题（请参阅我问题的更新）。在我的问题更新中，您能否确认（或澄清）我对这些不同字符集与会话字符集的理解？此外，您似乎需要根据您查询的表在应用程序中指定不同的会话字符集。如果要查询Unicode，请使用UTF8或UTF16。否则，请使用拉丁语。如果桌子上同时有这两种东西，事情会变得复杂起来，但我想不出有哪一天我会把它们混在一起。