當從SQLA中的86列組成的表中選擇所有列時,我始終得到錯誤Row size or Sort Key size overflow
。避免這種錯誤的唯一方法是減少選擇中的列數,但這是一個非傳統的解決方案。必須有一種方法可以在一個select語句中從該表中選擇所有列。Teradata SQLA:行大小或排序鍵大小溢出
賞金
我加入這個獎金,因爲我無法破解我的方式過去的這個問題的任何更長的時間。必須有一個解決方案。現在,我從具有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中遇到同樣的錯誤,但在ODBC配置中將字符集更新爲ASCII或拉丁文模式後,我可以很好地進行選擇。
Rob,你能提供關於這裏發生的事情的見解嗎?我的理論是,因爲它在拉丁語集中,所以使用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);
您是否在BTEQ中嘗試了相同的SELECT?是否有與此消息關聯的錯誤號碼? – 2012-08-08 13:08:16
它不會在BTEQ腳本中執行。它成功執行'***查詢完成。找到2行。 86列返回.'。 – oscilatingcretin 2012-08-08 13:40:42
但是,當我在我的測試.NET應用程序中運行完全相同的SQL時,出現「行大小或排序鍵大小溢出」錯誤。 – oscilatingcretin 2012-08-08 14:09:09