2012-08-08 172 views
1

當從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); 
+0

您是否在BTEQ中嘗試了相同的SELECT?是否有與此消息關聯的錯誤號碼? – 2012-08-08 13:08:16

+0

它不會在BTEQ腳本中執行。它成功執行'***查詢完成。找到2行。 86列返回.'。 – oscilatingcretin 2012-08-08 13:40:42

+0

但是,當我在我的測試.NET應用程序中運行完全相同的SQL時,出現「行大小或排序鍵大小溢出」錯誤。 – oscilatingcretin 2012-08-08 14:09:09

回答

2

沒有看到你的表定義你使用UTF-16,而不是UTF8您SESSION CHARSET考慮?

你的錯誤消息的一些更多的研究,發現了這個post表明UTF-16可以提供你返回UTF8否則不會記錄的能力。

編輯: 如果你從我上面分享的鏈接,對於給定的VARCHAR(n)的召回字節來存儲情況如下:

  • 拉丁語:n個字節
  • UTF8 :N * 3個字節
  • UTF16:N * 2個字節

這將意味着,在一個UTF8會話的VARCHAR(4000)UNICODE字段應該需要12KB。如果您必須始終處理UNICODE數據,則可以將您的默認會話字符集保留或更改爲UTF16。根據我的經驗,我沒有必須使用UNICODE數據,所以我不能告訴你改變字符集的缺陷可能會導致數據庫中其他地方的LATIN數據出現什麼問題。

希望這會有所幫助。

+0

甜。更改爲UTF16已爲此工作,並且您可能讓我找出有關此錯誤的其他問題(請參閱我的問題的更新)。你能確認(或直接設置)我對這些不同的字符集與我的問題更新中的會話字符集的理解嗎? – oscilatingcretin 2014-04-18 17:14:45

+0

此外,您似乎需要根據您查詢的表在應用程序中指定不同的會話字符集。如果您要查詢Unicode,請使用UTF8或UTF16。否則,使用拉丁語。如果這兩張桌子都是由兩個人組成的,這會變得複雜,但我想不出什麼時候我會混合組合。 – oscilatingcretin 2014-04-18 17:17:57