Accessを複数人で使うと、なぜ壊れるのですか?同時書き込みと強制終了を再現した

Accessを複数人で使うと、なぜ壊れるのですか?

書き込みの途中で、PCや通信が止まるからです。共有フォルダーのAccessは、全員が1つのファイルを直接読み書きします。Microsoftのサポートページによると、データの変更が途中で中断されると、Accessはファイルに「破損」の印を付けます。

通信が切れる、電源が落ちる、強制終了する。どれも書き込みが途中で止まります。Microsoftは同じページで、共有ファイルを複数の人が同時に直接使うと、まれに壊れることがあるとも書いています。長いテキストの項目をよく編集すると、危険は少し上がります。

Access引越しが手元で試した結果、人数を増やしても壊れず、書き込みの最中で止めると壊れました。

この実験には限界があります。結果はどれも、同じPCの中で共有フォルダーを開くループバック(\\localhost)でのものです。社内LAN、Wi-Fi、NASで通信が途中で切れる場面は再現していません。壊れる主な引き金はその切断なので、「10人でも失敗0件」は、通信が切れない条件での結果として読んでください。

「修復が必要」が何度も出るなら、Access・オフコンの引越しも選択肢に入ります。

Accessは、何人まで同時に使えますか?

Microsoftの「Accessの仕様」では、同時に使える人数の上限は255です(Microsoft 365・2024・2021・2019・2016)。実験では10人まで試し、書き込みの失敗は0件でした。人数で変わったのは待ち時間です。

実験では、1・2・3・5・10人が、それぞれ200回ずつ書き込みました。受注を1行足す操作と、全員が同じ1行の数を1つ増やす操作を交互にしています。各人数で3回ずつ試し、行数と数が合うかも確かめました。

ロックのエラーは、書き込みの最中には1回も返ってきませんでした。かわりに、ファイルを開く瞬間に断られることがありました。

エラー番号は-3810で、文面は「認識できないユーザーがデータベースを開けない状態、またはロックできない状態にしています」です。15回の試行で計6回起き、開き直すと入れました。

ロックファイルを説明したMicrosoftの以前のサポート記事(アーカイブ)にも、人数の注記があります。追加や更新が多いなら、25〜50人までにするのがよいという内容です。人数で壊れるというより、待ちと開けない回数が増えると考えるのが実験に合います。

書き込みの途中でPCが止まると、ファイルはどうなりますか?

多くは無事でしたが、20回中1回は開けなくなりました。3人が書き込んでいる最中に、1人だけのプロセスを止める試しを10回、全員を止める試しを10回しました。開けなくなった1回は、全員を止めたほうです。

開けなくなったファイルは、最適化/修復をかけると開けるようになりました。行数と数の食い違いもありませんでした。Microsoftも、失われるのは多くの場合、1人の最後の操作ぐらいだと説明しています。

止めたあとには、ロックファイル(.laccdb)が20回中19回残りました。Microsoftの以前のサポート記事によると、開いた人のコンピューター名などを記録するファイルです。最後の人が閉じると消えます。全員が閉じたのに残っていれば、誰かが途中で止まった跡か、破損の印が付いた跡と見てください。

使っている最中にコピーしたバックアップは、使えますか?

開けても、中身が食い違っていることがあります。3人が書き込んでいる最中のファイルをそのままコピーする試しを、20回しました。20回とも開けましたが、16回は足した行数と更新の回数が合いませんでした。

実験の書き込みは、1回ごとに20行を足し、同じ1行の数を1つ増やします。そろったファイルなら、足した行数は数のちょうど20倍です。コピーでは、8〜120行の差が出ました。8行のように20で割り切れない差は、1回分の書き込みが途中まで入っていたことを示します。

書き込みを止めたあとの元のファイルは、そろっていました。コピーは開けるので、食い違いに気づきにくいのが厄介です。昼休みにコピーしたファイルも、この状態でありえます。バックアップは、全員が閉じている夜や朝に取ってください。

この実験は、どうすれば再現できますか?

スクリプト1本で再現できます。1人をPythonの1プロセスに見立て、Accessのドライバー(ACE ODBC 64bit)で書き込みます。共有フォルダーは、同じPCの \\localhost\C$ をSMBで開いて代わりにしました。実験は2026年10月16日、Windows 11のPC1台で行いました。

強制終了とコピーの試しでは、2,000行を入れたファイルを使いました。3人が、2,000字の長いテキストを持つ行を20行ずつまとめて(トランザクション)足し続けます。止めるまでの時間は1〜4秒の間で毎回変えました。

使ったコード(access_concurrent.py)の要点は、次の数行です。

# 共有フォルダー上の .accdb に、N個のプロセスから同時に書き込む
path = r'\\localhost\C$\Users\Public\acc-concurrent\a.accdb'
ps = [spawn(path, w, 200, start, out[w], 'fixed') for w in range(n)]
# 3人が書き込んでいる最中に、後片付けをさせずに止める(TerminateProcess)
time.sleep(wait); ps[0].kill()
st = check_file(local)   # DAOで開けるか、行数と数がそろうか

限界もあります。同じPCの中の通信なので、本物のLANやNASより速く、途中で切れません。止め方もプロセスの強制終了だけで、ケーブルを抜く試しはしていません。

回数も各20回なので、「20回に1回壊れる」と一般化はできません。数字は「この条件ではこうなった」として読んでください。

Accessを壊れにくくするには、何から手を付ければよいですか?

まずファイルを分割し、バックアップを全員が閉じている時間に移します。Microsoftが勧める分割では、テーブルだけのバックエンドを共有フォルダーに置きます。画面や帳票のフロントエンドは、各PCに配ります。

分割しても、データのファイルは1つを皆で使うので、途中で止まれば壊れえます。私が仕組みを作るときは、次の順で手を打ちます。

1. 作業の前に、全員が閉じた状態でファイルのコピーを取る
2. 分割して、フロントエンドを各PCに配る
3. 無線LANやスリープでつながりが切れやすいPCを、書き込む人から外す
4. それでも月に何度も修復が要るなら、データをサーバーのデータベースかWebアプリへ移す

サーバーのデータベースに無償のSQL Server Expressを使うときは、上限を先に確かめます。SQL Server 2022のExpressでは、1つのデータベースは10GBまでです。使うメモリ(バッファープール)は1,410MBまでです。自動でバックアップを動かすSQL Server Agentもありません。

AccessからはODBCのリンクテーブルでつなぎます。一度に多くの行を読むフォームは、そのままだと開くまで待たされることがあります。毎晩のバックアップを仕掛ける人と、残っているかを確かめる人も決めておきます。

4つ目に進むときは、先に中身を数えます。手順は作った人がいないAccessの中身を数える手順に書きました。

このサイトで相談するには?

Access引越しでは、「ときどき修復が必要と出る」という段階からでも相談を受けています。何をどう頼むか決まっていなくても大丈夫です。御社のやり方に合わせて、進め方を一緒に考えます。

準備は要りません。無料で相談するからお送りください。