0

CODBCRecordset (CodeProject にあるクラス) を使用して、39 列のテーブルで単一のレコードを検索しています。レコードが見つからない場合は、CRecordset::Open の呼び出しで問題ありません。レコードが条件に一致する場合、CRecordset::Open が呼び出されたときにメモリ不足の例外が発生します。クエリ内のすべての列を選択しています (同じ where 句を持つ列の 1 つだけを選択するようにクエリを変更すると、例外はありません)。

これはCRecordsetの制限によるものだと思いますが、制限について教えてくれるものは何も見つかりません。テーブルには 39 列しかありません。

誰かがこの問題に遭遇しましたか? もしそうなら、あなたは回避策/解決策を持っていますか?

これは、Visual Studio 6.0 を使用する MFC プロジェクトです。

クエリは次のとおりです (ここでフォーマットされているため、スクロールバーなしで表示されます)。

    SELECT `id`, `member_id`, `member_id_last_four`, `card_number`, `first_name`,
           `mi`, `last_name`, `participant_title_id`, `category_id`, `gender`,
           `date_of_birth`, `address_line_1`, `address_line_2`, `city`, `state`,
           `zip`, `phone`, `work_phone`, `mobile_phone`, `fax`, `email`,
           `emergency_name`, `emergency_phone`, `job_title`, `mail_code`,
           `comments`, `contract_unit`, `contract_length`, `start_date`,
           `end_date`, `head_of_household`, `parent_id`, `added_by`, `im_active`,
           `ct_active`, `organization`, `allow_members`, `organization_category_id`,  
           `変更日`
   FROM `参加者`
   WHERE `member_id` = '27F7D0982978B470C5CF94B1B833CC93F997EE23'

コピーしてクエリ ブラウザに貼り付けても、1 つの結果しか得られません。

より詳しい情報：

id を除く select ステートメントの各列をコメントアウトしました。クエリを実行しましたが、例外はありませんでした。

次に、体系的に各列を 1 つずつ調べてコメントを外し、コメントを外すたびにクエリを再実行しました。

コメント欄のコメントを外すと、エラーが発生します。

これは次のように定義されます (MySQL を使用): LONGTEXT

4

3 に答える 3

2

C ODBC Recordset :: Open（）を呼び出していると仮定できますか？または、より正確には、次のようなものです。

CDatabase db;
db.Open (NULL,FALSE,FALSE,"ODBC;",TRUE);
CODBCRecordSet rs (&db);
rs.Open ("select blah, blah, blah from ...");

応答後に編集：

さまざまなODBCドライバーには、無効なフィールド長を取得することによって引き起こされると思われる既知のバグがいくつかあります。これらのリンクを参照してください。

これは、CRecordsetがフィールドを保持するのに十分な大きさのバッファーを割り当てるためであると思われます。列がゼロの長さを返すため、最大8ビットサイズ（255バイト）ではなく、最大32ビットサイズ（〜2G）として解釈されます。言うまでもなく、フィールドに十分なメモリを割り当てることはできません。

Microsoftはこれを問題として認識しています。解決策については、次を参照してください。

質問の補遺の後に編集：

したがって、MySQLフィールドがLONGTEXTであるとすると、CRecordSetはそのフィールドに可能な最大サイズ（2G）を割り当てようとしているように見えます。コメントフィールドに本当に2ギガが必要ですか？80 wpmで入力すると、6cpwはタイピストがそのフィールドを埋めるのに7年強かかり、休むことなく1日24時間働きます:-)。

データベース内のすべての列を調べて、適切なデータ型があるかどうかを確認すると便利な場合があります。特に現在のODBCクラスがそれほど大きなフィールドでは機能しないという事実に照らして、2Gカラムを使用できないと言っているのではなく、それが必要であることを確認する必要があります。

于 2008-12-02T06:20:30.317 に答える
0

Paxの応答を読んでください。それはあなたに問題が起こる理由についての素晴らしい理解を与えます。

回避策：

このエラーは、（TEXT、LONGTEXTなど）として定義されたフィールドがNULL（および場合によっては空）の場合にのみ発生します。フィールドにデータがある場合は、フィールドのデータのサイズのみが割り当てられ、最大サイズは割り当てられません（これによりエラーが発生します）。

ですから、どうしてもこれらの大きなフィールドが必要な場合があります。考えられる解決策は次のとおりです。

  1. データベースのフィールドにデフォルト値を指定します。（すなわち。'<blank>'）
  2. 次に、値を表示するとき。デフォルト値が見つかった場合は、NULL/空を渡します。
  3. 次に、値を更新するとき。NULL /空が見つかった場合は、デフォルト値を渡します。
于 2008-12-02T07:03:34.237 に答える
0

このエラーは、可能な限り最大の LONGTEXT を保持するのに十分な大きさのバッファーを割り当てようとしたことが原因であるという Pax の提案に同意します。クライアントは、データをフェッチするまで、そのデータがどれほど大きいかを知りません。

LONGTEXT は実際、ほとんどのアプリケーションで必要になるよりもはるかに大きくなります。代わりに、MEDIUMTEXT (最大サイズ 16MB) または TEXT (最大サイズ 64KB) の使用を検討してください。

PHP データベース インターフェイスにも同様の問題があります。通常、PHP にはメモリ サイズの制限があり、LONGBLOB または LONGTEXT のフェッチはその制限を超える可能性があります。

于 2008-12-03T03:33:59.433 に答える