1

SQLA で 86 列からなるテーブルからすべての列を選択すると、常にエラーが発生しますRow size or Sort Key size overflow。このエラーを回避する唯一の方法は、select の列数を減らすことですが、これは型にはまらない解決策です。1 つの select ステートメントで、このテーブルからすべての列を選択する方法が必要です。

バウンティ

この懸賞金を追加するのは、これ以上この問題をハッキングすることができないためです。これには解決策が必要です。現在、Unicode 列を含むテーブルから選択しています。これにより、行サイズが容量を超えていると想定しています。Session Character Set=UTF8接続文字列から削除すると、エラーが発生しますThe string contains an untranslatable character。NET データ プロバイダー 14.0.0.1 を使用しています。サイズを大きくする方法はありますか？

アップデート

ロブ、あなたは感銘を与えることは決してありません! UTF16 を使用するという提案が機能します。ODBC設定を更新した後、SQLAでも機能します。私の問題は、ASCII、Latin、UTF8、および UTF16 を理解していないことだと思います。

また、すべてラテン語の列で構成される 80 列のテーブルもあり、そのうちのいくつかは「varchar(1000)」です。UTF8 および UTF16 で SQLA から選択すると同じエラーが発生しますが、ODBC 構成で文字セットを ASCII またはラテン モードに更新した後、問題なく選択できます。

ロブ、ここで何が起こっているかについての洞察を提供できますか? varchar(1000)私の理論では、これはラテン語セットに含まれているため、UTF8 または UTF16 を使用すると、より大きなバイト セットに変換され、特に'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

テーブル定義を見ずに、UTF8 の代わりに UTF16 を使用することを検討しました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 に答える