1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ACCESSランタイム用開発で2GBの壁に苦戦した話

Posted at

経緯

ACCESSのクエリやマクロで半自動化されてた既存のシステム(複数DBを組み合わせて使われてた)をランタイムで動かせるように統合してたら2GBの壁にぶつかった。
テーブル作成クエリ、追加クエリの処理が重たい。

やってみたこと

[NG]重いテーブルを別DBに分けてリンクテーブルにしてみた

 一番よく見る対処方法で、私も「A.accdb」のテーブルを別DB「B.accdb」にすれば容量は問題なくなると思っていた、時代がありました。

残念ながらVBAで処理を実行すると「B.accdb」のリンクテーブルにテーブル追加するクエリの処理で「A.accdb」の容量が増えてました。「A.accdb」を最適化すれば容量は減りましたが、「A.accdb」のVB実行中に「A.accdb」の最適化をする処理が作れずどうしようもなくなりました。

[NG]SELECTクエリにしてVBでクエリの結果を取得→別DBに書き出しを行った

テーブル作成クエリを使うと容量が増えてしまうかと思い、VBで「B.accdb」へクエリの結果を書き込もうとしました。とても時間をかけてしまいましたが、容量というか処理が重すぎてACCESSは先に進まなくなってしまいました。

[OK]テーブル作成クエリ、追加クエリを参照のみのクエリにした

既存の動きはクエリ1の結果をテーブル1に書き出し、クエリ2の結果をテーブル2に書き出し、クエリ3はテーブル1とテーブル2を参照していました。
このクエリ1、2の書き出しがそもそも要らなくて、テーブルを作成せずにデータを参照する「選択」タイプのクエリに変更し、クエリ1、2をクエリ3から参照するように変更しました。
image.png
すると長いものだとクエリ1つで2時間くらいかかっていたものが3つ合わせて20分、容量も食わないという驚きの事実がありました。。

私が初心者なので分からなかっただけでACCESSを勉強してきた人にはもしかしたら常識なのかもしれないけれどこの方法をGoogle先生に教えてもらえてたらどれだけよかったかと思います。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?