Accessは壊れやすいということをよく聞く。
実際よく壊れる。
テーブルが破損して修復できなくなると最悪である。
なので、バックアップは毎日とっておくことを推奨する。

もともとAccessは共有での利用を前提としていないようだ。数人程度なら共有しても使えるといった程度だと聞いた。
なので、常時10人以上で共有利用すると壊れやすくなる。
これは、ユーザーフォームとテーブルとを別ファイルに切り分けて、リンクテーブルで利用した場合でも同様なようである。

ただし、バックエンドをDBサーバー（SQLServer、oracle等）で利用する場合は話は別で、この場合テーブルが壊れることはまず無い。
しかし、ユーザーフォーム側は壊れるケースは、確率は低いが依然として残る。

壊れやすいコーディング

私の経験では、データの投入や更新・削除時に、
　Recordset.Open TableName
などでRecordsetを開いた状態でフィールドにデータを投入するようなコーディングの場合が壊れやすいと感じた。
普段問題なく動いていても、エラーで止まるときはだいたいAddNewコマンドやUpdateコマンドの部分で停止している。

テーブルが壊れてしまってデータ投入や更新ができなくなってしまっている状態である。
もしかしたら別の部分で破損が進んだのかもしれないが、最終的にはだいたいこの部分で止まっていた。

100万レコードを超えるテーブルを１時間ほどかけて更新・追加・削除を行う日時処理をしていたツールがあったが、ひどいときは毎日テーブルが破損していて、修復に多大な労力が必要なこともあった。
（限界を超えた利用だということは分かっていても、Accessを使う以外の手段がなかったためやむを得ず利用していた状況）

この状況を改善したのが、INSERT・UPDATE・DELETEのSQL構文に置き換えてSQLにてデータの登録・更新を行う方針に変更したこと。

たったこれだけである。
この改修で、毎日のように破損していたテーブルが、1か月近く壊れずに運用できるようになった。
（最大約100人が参照し、同時接続が常時20人以上の超高稼働ツールで、しかもNAS上でテーブル用のファイルを共有している状態にしてはかなり良くなったと言える）

DBなのでSQLでのデータ登録・更新は理にかなっている。
コーディングをスマートにとか見栄えや作成しやすさを優先しているとこのような事態になる。
本末転倒である。
きちんとしたインフラが整っている会社と、中小のようなとりあえずLANでつなげた程度の会社では、ツールの作り方にも若干の工夫が必要になるということである。

SIerを経験して、その後にAccess単体のVBAでツールを作っている人は、バックエンドがDBサーバーのときのコーディングだとAccessツールに負担を掛けるコーディングになっているかもしれないということだ。

まあ、DBサーバー導入しろということになるのだが、中小企業ではいろいろと対応が難しいようだ。
とすると、壊れにくくツールを作るということになる。
これは試行錯誤を重ねて環境に合わせていくしかない。

これはあくまでも私の経験の話である。
誤解の無いように追記すると、
　Recordset.Open TableName
でのコーディングをしてはいけないということではない。
私もテーブルのデータを読み込んで配列に保存するときなどよく利用している。
いろいろなサイトや書籍でもサンプルが多く掲載されている。
大量のデータを効率よく取り込むには Recordset.Open が使いやすい。
要は使いどころということです。

もっと良い対策があるかもしれないので、いろいろと探してみたいと思う。