＊ Amazon Access 関連書籍情報

単体テスト・結合テストももうばっちり。さぁユーザーに納品しよう。
え？サーバーに置いて、共有して使うつもりだった？それは初耳だけど、まー大丈夫でしょ、みんなで開いたって。
最適化？ああ、なんか開発してる間にバカでかくなったから納品する前に一回やったけど、もういいでしょ？

…..と甘く考えている方はいませんか？それは大きな間違いです。

Access はマルチユースに極端に弱く、そんなことをしたら mdb 破損の確率が格段に上がります。

Access の排他制御は前述のとおりページ単位です。(Access2000 以降を除く) その機能はおよそ誉められた代物ではありません。というか、サーバープロセスの存在しない単なるファイル共有なんですからいたしかたありません。

もともと Access というのは、シングルユースで使うことを前提に作られました。最初に生まれた頃はネットワークも今ほど発達していない時代。サーバーに置いて共有して使う、なんていうネットワーク環境はおいそれと実現できない時代でした。
だからといって、共有して使ったら絶対に壊れるというわけではないところが困り者です。こうすれば壊れる、と実証できるのなら、Mico○osoft のサポートに即刻電話して、詳細な再現手順を報告すれば次期バージョンでは治る可能性もありますし、Micro○oft だって「mdb は壊れやすい」なんてことは百も承知ですから、そういった報告を待っているのです。

この、mdb が壊れるという現象は、定期的に最適化することで確率を相当数下げることができます。
どのようなシステムでも、なんらかのタイミングで最適化するしくみは絶対に必要です。
（もちろん、同時にバックアップも必要）
このしくみが無いシステムはどんなにすぐれた設計でも「駄作」と呼ばせていただきます。安定稼動しないデータベースシステムなど、意味がありません。
（もっとも、Jet エンジンに安定稼動を求めること自体が間違いだという説もありますが）

そうは言っても、短期間、低コストででお手軽に構築・開発ができる Access で、運用さえうまくすれば安定（に近い形）したシステム稼動ができるのであれば、それにこしたことはありません。
現在、私が考える破損の確率が少ない、また被害が少ないシステム構築は以下の通りです。

1. テーブル部とクエリー・フォーム・レポート・モジュール部は完全に別 mdb ファイルに持ち、データはリンクテーブルとして扱う
2. 各処理を起動するメニューは Visual Basic，もしくは別 mdb ファイルで作成し、起動した処理が終了したら該当 mdb ファイルを最適化する
3. １日に１度はデータ部 mdb ファイルのバックアップ、最適化を行う

•１．について・・リンクテーブルにすることによって制限（CurrentDB のテーブルでも Seek メソッドが使えない等）は発生しますが、もし mdb が破損した場合（破損するのはフォーム・レポート・クエリー部分の確率が高い）、プログラム部分の mdb だけならデータの整合性等気にせずにバックアップから簡単に戻すことができます。
実際の運用に入った場合このメリットは計り知れません。

•２．について・・最適化は、開いて閉じたらしたほうがよい、と考えるのが得策です。いくらバックアップから簡単に戻せるとはいっても、たびたび壊れていたらユーザーの信頼を失ってしまいます。
または、最適化の代わりにそのつどバックアップから戻してもいいかもしれません。こっちの方が早いかも。

•３．について・・現在はスケジューリング機能など充実していますので、これを利用しないテはないでしょう。

システム開発はケースバイケースです。もちろん、これが最良だというつもりはありません。
が、最低限これくらいのしくみを作っていかないと、あとでトラブルに見舞われたときに対処できません。

さらに詳しく知りたいアナタは、メーカーの出す情報もしっかりチェックしましょう！
Access2000 では、「終了時に最適化」というオプションが増えました。ただ、すでに壊れているのに気づかずに使っていたなんて場合、mdb を閉じて最適化されたときにその破損が露呈してしまい、どうにもならなくなってしまったなーんて話も実際によく耳にします。
できれば、このオプションには頼らないほうがいいかと。バックアップと最適化はセットで行うことをお勧めします。