プロフィール

alphan

Author:alphan
FC2ブログへようこそ!

暗号ツール
最近の記事
カテゴリー
カレンダー

09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

月別アーカイブ
最近のコメント
最近のトラックバック
FC2カウンター

天気予報


-天気予報コム- -FC2-

ブロとも申請フォーム
ブログ内検索

RSSフィード
リンク
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

表題の文章が下手で何言ってるか分からないですね。

Access2000とAccess2002でしか確認していませんが、いわゆる1対多の関係で2つのテーブルをリレーションでつないでいます。
この1側のテーブルに1レコードINSERT。
対応する多側のテーブルに1万レコードをINSERT。
リレーションは連鎖更新と連鎖削除を指定しています。

この状態で1側のテーブルの1レコードを削除すると、連鎖削除で多側のテーブルの1万レコードも同時に消えてくれます。
多側のレコードに関するコーデイングが不要で便利ですよね。 RDBはこれだから楽です。

こんな感じで処理を作成していましたが、ある時に1側のテーブルをレコードソースとするフォームを作る必要が出ました。
このフォームでは1側のテーブルの1レコードの内容を表示するもので、処理が完了すると1側のテーブルのレコードも削除します。
(多側のレコードも実際には付随するフォームで表示しますが、処理終了でこのフォームも多側のテーブルのレコードもいっしょに削除します。)

1側のフォームのCloseイベントで、多側のフォームを終了した後、1側のテーブルにDELETEをかければ全部の(多側のテーブルも含めて)レコードが削除されるので大変便利に使っていました。

ところがこの多側のレコード数が数千レコード程度までは大丈夫でしたが、1万レコード程度になると「メモリ不足です」なるコード3035のメッセージがAccessから出力されて、トランザクションとしてRollBackされてしまいます。
対象レコード数がAccessにとって多すぎるのかと思いましたが、テーブル上の操作ではきれいに連鎖削除できます。

色々調べたところ、フォームのレコードソースに1側テーブルが指定されている場合にのみ発生するようです。
しかし、リレーションの連鎖をさせずに自分で多側を先にDELETEするコードを追加すると大丈夫です。

つまり、Accessでのリレーション制御は、フォームやレポートやクエリを絡ませると、レコード数が少し増えただけでギブアップされてしまうようです。
ちなみに、テーブルをSQLサーバに移したらまったくこのようなエラーは発生しなくなりました。

「メモリ不足です」だけでなく「クエリが複雑すぎる」旨のエラーになることもあるなどと、同じMSのSQLサーバの移行用の宣伝にも書いてあるのを発見しました。

なを、そうとも知らずにメモリを512MBから1GBに増設してみて全く現象が変わらないことに気づいてから調べた私って・・・
スポンサーサイト

コメントの一覧

コメントの投稿














管理者にだけ表示を許可する

トラックバック

トラックバックURL
→http://alphan.blog96.fc2.com/tb.php/22-9677caeb
この記事にトラックバックする(FC2ブログユーザー)

前後のページの案内

バンドメンバー募集のキング 新着コールマン通販
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。