以下では、「Accessでデッドロック？レコードレベルロックと注意点を押さえる」をテーマに、Accessをマルチユーザー運用する際に生じ得るロック問題（デッドロックや競合）について解説します。Accessはシンプルに使える反面、複数人で同時にレコードを編集しているとロック競合が起こりやすく、場合によっては実質的なデッドロックに似た状況が発生します。フォームのロック設定やテーブルのサイズ・ページ単位ロックの仕組みを理解し、トラブルを未然に防ぎましょう。

1. デッドロックとは？Accessでもあり得る？

デッドロックは、データベースで2つ以上のトランザクションが互いに相手のロックを待ち続け、永久に進まない状態を指します。SQL Serverなど大規模DBでよく話題になりますが、Access(ACE/Jetエンジン)でも競合・衝突が激しい状況では、事実上の“行き詰まり”が起こることがあります。

• ただしAccessでは厳密なトランザクション管理やデッドロック検出がSQL Serverほど高機能ではないため、実際には競合（Write Conflict） ダイアログが出て「保存／コピー／破棄」を迫られたり、ファイルロックが掛かったまま進まない状況が起こることも
• 複数ユーザーが同じレコードを同時に更新したり、ネットワーク遅延でロックが長時間保持されると、Accessの内部ロック制御がトラブルを起こす原因になりやすい

2. レコードレベルロックとページレベルロックの概要

ないものはない！お買い物なら楽天市場

2.1 Accessのロック機構

Access(ACE/Jet)の内部ロックはページ単位と呼ばれ、デフォルトでは2KB/4KBのデータ単位でロックする仕組みです。

• しかし、フォームのプロパティ設定やAccessのバージョン・状況によっては「編集中のレコードのみロック」「ページロック」などを切り替えられる

2.2 レコードレベルロック(Edited Record)

• フォームのプロパティ 「レコード ロック」 を「編集レコードのみロック」にする
• ユーザーがあるレコードを編集モードにすると、その1レコードだけが他ユーザーから書き込み不可状態に
• 読み取りはできても、上書きはできない → 保存確定まで待たされる

メリット

• 競合が発生しにくく、同じページにある他のレコードが巻き添えでロックされる現象を抑えられる

デメリット

• 運用やアプリケーション設定によってはロックが長時間保持されると、他ユーザーが同じレコードを編集できず効率が落ちる

3. フォームでのロック設定：編集レコードのみ／全レコード／なし

フォームのプロパティにある「レコードロック」(RecordLocks)で3パターン指定できます。

1. なし (No Locks)
   • デフォルト設定。複数ユーザーが同じレコードを同時に編集できるが、上書き競合が起きたときに「他のユーザーが更新済み、あなたの変更は上書きしますか？」などのダイアログが出る
   • 一見自由だが、Write Conflictが頻発する場合は混乱しやすい
2. 編集レコードのみ (Edited Record)
   • 編集中のレコードだけロックされ、他ユーザーは書き込み不可になる（閲覧は可）
   • 競合の発生を抑えやすい
3. 全レコード (All Records)
   • フォームが開いている間、表示中のレコードすべてがロックされる → 同じテーブルを他ユーザーが編集できない
   • 共同作業をほぼ許さない過激設定で、通常あまり使われない

現場では「編集レコードのみ」を選択し、ユーザーが少なめでそこまで大きくないテーブルなら競合を最小にできるケースが多いです。

4. 競合や擬似デッドロックを回避する運用例

1. フロントエンド分割
   • テーブルをバックエンドファイルにし、各ユーザーが自PCのフロントエンドからリンクテーブルでアクセス。衝突を少しでも軽減
2. 短いエディット
   • 大事なフォームで編集モードに入ったまま他作業をしない
   • 編集が終わったら保存(Enter or 移動)してロックを解除する
3. 連続フォームの仕組み
   • 連続フォームだと複数レコードを一度に表示して編集しがち → 競合率が高くなる場合あり
   • 重要データは単票フォームで編集し、1レコードだけロックする運用
4. データの分割設計
   • 頻繁に編集されるテーブルを分割し、同じレコードをみんなが触らないように業務ルールを作る
5. 外部DB(例：SQL Server)
   • Access(フロントエンド) + SQL Server(バックエンド)に移行すると、サーバーがロック制御し、競合検出やデッドロック処理が洗練される

5. Write Conflictダイアログが出たらどうする？

Accessで複数ユーザーが同じレコードを変更しようとすると、“Write Conflict” ダイアログが表示される場合があります。選択肢は下記の通りです：

1. 保存 (Save Record)
   • 他ユーザーの変更を上書きする
2. コピー (Copy to Clipboard)
   • 自分の更新内容をクリップボードに退避し、再度貼り付けするなど手動で解決
3. 破棄 (Drop Changes)
   • 自分の変更をあきらめ、他ユーザーの更新を優先する

運用ルールでどちらを優先するかなど、ユーザーに周知しておくと混乱が減ります。

6. 実質的なデッドロックへの対策

• Accessにおけるデッドロックは、厳密には同時に行が互いをロックして待ち続ける状態
• 実際にはAccessが競合検出し、**“Write Conflict”**やエラーコードで中断させることが多く、永遠に待ち続けるシチュエーションは少ない
• 最善策:
  1. 編集レコードだけロックを徹底し、
  2. 長時間編集せず（同じレコードをずっと開きっぱなしにしない）、
  3. 頻繁に保存 (レコード移動)
• もし高度なトランザクション管理が必要ならSQL Serverなど本格的なDBMSへ移行を検討

7. まとめ：ロック設定と運用がデッドロックもどきの発生を防ぐ

1. フォームの「レコードロック」プロパティで、「編集レコードのみ」を設定
2. 同時編集が多いときはフロントエンド分割やSQL Serverバックエンドを検討
3. 長時間の編集モードを避ける
   • 1レコードにとらわれたまま他の操作をすると、他ユーザーが待たされる → 無駄な競合やWrite Conflictが発生
4. Write Conflictダイアログの周知
   • ユーザーがどの選択肢を選ぶかを理解し、上書き or 破棄のルールを明確に
5. 安定運用:
   • データ設計を見直し、1つのレコードを複数人が同時に触らなくて済むよう業務フローを工夫

Accessで“デッドロック？”と思われる現象が起きる場合でも、ロック設定や使用方法を見直せば多くは緩和できます。もし本当に多数ユーザー・高更新頻度が必要なら、SQL Server連携など次のステップに移行し、安全かつ高速なデータ管理を実現しましょう。

関連記事

• マルチユーザー運用時の注意：フロントエンド分割＆レプリケーションの概要
• バックアップ・リカバリと災害対策
• テーブル設計の基本（リレーショナルデータベース入門）

以上がAccessでのレコードロックやデッドロックもどきへの対応策です。ロックの仕組みを理解し、“編集レコードのみロック”や良好な運用ルールを組み合わせるだけで、トラブルは大幅に減らせます。ぜひ試してみてください。

DMM

まー

駆け出しブロガー

X

入社した会社では、Accessを活用した基幹システムが長年運用されていました。しかし、開発者の高齢化により保守が困難となり、システムの維持・更新が急務に。 ほぼAccessに触れたことのなかった私は、ゼロから学びながら基幹システムを再構築してみることに。ついにはAccessによるシステム開発エンジニアとしてのスキルを身につけるまでに成長。 元々の業務のノウハウとそれを効率化するためのツール(Access)によって業務効率化システムをいくつも開発してきました。 みなさんの”なにか（業務のノウハウ）”とAccessで業務効率化を実現するお役に立てれば幸いです。 月３０万の高配当投資も行っています。最新の銘柄情報もお届けしていきます。