※このページは2013/12/18に大幅に書き換えています。
仕事、特にオフィスワークをしているとDBとの関わり無しでは仕事にならない。
そもそも、通常のRDBMSは一つないし複数のテーブルごとに一個の物理ファイルとして作成し、それら複数の物理ファイルを一つのデータベースとして扱う方式。たとえ一つのテーブルが一定以上の容量になったとしても、ある程度自動的にテーブルを分割するため、2GB程度で容量オーバーになることは無い。
しかし、Accessの場合はファイル「.mdb(.accdb)」にすべてのテーブルを格納してしまう。
今どきのファイルシステムであれば、1ファイル2GB以上のデータは簡単に作れる。ただ、過去のしがらみか(Windows 95とか98の際には、ファイルシステムにFAT16というものが使われていて、これは2GB以上のファイルが作成出来なかった。)自社のSQL Serverを入れたいためかは不明だが「.mdb(.accdb)」形式では２GB以上のデータは作れない。２GBを超えてしまうと「引数が無効です」というエラーが表示されてしまい、それ以降内部データを削除するまではデータの追加ができなくなる。
このようなエラーが起きると、その後の作業が止まってしまう。10年程度前であれば、Accessで2GB以上のデータを使うことなんて稀だったのかもしれない。しかし、今の時代、2GB程度で止まってしまうのは困る。
とはいえAccessにこのような制限があるのは事実なので、これとうまく付き合っていき、かつ対応する方法を記述する。
1.応急処置で「データベースの最適化/修復」を行う
RDBMSではおなじみとも言える作業。そもそも、Accessのテーブルにあるデータを消したといってもすぐにAccessのサイズが小さくなるわけではない。
ただ削除しただけだと、データはいぜん「.mdb(.accdb)」ファイル内に残り続け、認識されるファイルサイズは変動しない。
そこで、「削除を適用させる（ファイルサイズに反映させる）」ために、「データベースの最適化/修復」という作業を行う事で、「.mdb(.accdb)」ファイルと内部のデータとを連携させる事が出来る。
図：Accessの容量変動イメージ
「データベースの最適化/修復」の方法は2003の場合はこっち、2010の場合はこのページに掲載されている。
で、当たり前なんだけど、この方法はあくまでもAccessの容量と格納されているテーブルの容量に乖離があるときにしか使えない訳で、テーブルの容量が大きい場合にはこの方法では対処不可能になる。
2.Accessを分割する
要は、Accessが1ファイルごとに2GB以上の場合に問題が出るわけなのだから、複数ファイルに分けてしまえばいいということ。
物理的にAccessファイルを分割し、互いの連携を「リンクテーブル」というAccessの機能で行う事で対応するというもの。
これなら、Accessで作成されていたクエリも、一部以外は使い回す事が可能となる。ここでいう一部だが、テーブル更新・削除クエリ（テーブル内部のみ削除するクエリの事。紛らわしい名前…）は使い回し可能だが、テーブル追加クエリでTableA.accdbやTableB.accdbにテーブルの追加ができないため、対策が別途必要になる。
なぜかというと、リンクテーブルという機能は「Access」へのリンクを作るのではなく、「テーブル」へのリンクのためである。つまり、リンクをする対象となるテーブルをリモートで作成することが出来ない。
さらにもう一つ、根本的な問題がある。それは、テーブル1個の容量が2GBを超える場合には対応できない。
3.別のRDBMSシステムを使用し、クライアントとしてAccessを利用する。
そんなことわかってるんだよ！
と言われそうな気がする。
といっても、わざわざDBサーバを起動させるようなやり方ではない。
RDBMSの中に「SQLite」というものがある。このシステム、Accessと同じように１ファイルにテーブルデータ等を保持する形式となっているのだが、容量制限が32TBまでとなっている。これをリンクテーブル先にすればよいのだ。
実際の作業方法は以下のページを参照してもらうとわかりやすい。
Accessでaccdbを使わずに他のDBを使ってみる ? SQLite編1
もちろん、SQLiteを使用するにもデメリットが存在する。上の3つ目のリンクに乗っているんだけど、処理が遅いということ。
現時点では、Accessの2GB制限は解除されることは無く、その方法も無い。
うまいこと工夫してやりくりするしか無いというのが現状。
追記
他のDBソフトで代用できないか、少し調べてみました。