概要
| この記事の結論 Accessの「データの競合」は、読み込んで編集しているレコードが、保存前に別の利用者や処理によって変更されたときなどに起きます。一人で使っていても、複数の画面やVBAが同じデータを更新すれば発生します。まず入力内容を退避し、最新データと照合してから必要な変更だけを反映しましょう。 |
この記事でわかること
- 同じレコードの更新が重なる仕組みと、一人でも競合する理由
- 警告画面の選択肢と、入力内容を守りながら対処する手順
- 共有利用のロック設定と、フォーム・VBAの更新順序の見直し方
- 一時テーブルやSQL Serverを利用するときの注意点
この記事の主な内容
- Accessのデータの競合とは 同じレコードの更新が重なる仕組み
- データの競合が出たときに最初に行う対処
- データの競合が発生する主な原因
- 共有利用で競合を減らす運用とロック設定
- VBA 更新クエリ SQL Server連携で確認すること
- 解決しないときの確認リストと相談の目安
- よくある質問
- まとめ
想定読了時間：約12分～約15分
1 Accessのデータの競合とは 同じレコードの更新が重なる仕組み
データの競合とは、同じレコードに対する複数の更新がぶつかり、そのまま保存すると他の変更を失うおそれがある状態です。「レコード」は、顧客や受注などの情報をまとめた1件分のデータを指します。警告が出た時点で、データベースの破損が確定したわけではありません。
同時刻でなくても保存順によって起きる
説明用の例として、担当者AとBが顧客ID1001の住所をそれぞれのフォームで開いた場面を考えます。Aが先に新住所を保存しても、Bの画面には古い内容が残っている場合があります。Bがその状態で変更を保存すると、競合が検出されることがあります。
このように、二人が同じ瞬間に保存ボタンを押す必要はありません。読み込みから保存までの間に別の更新が入ることが問題です。また、自分は電話番号だけを変えたつもりでも、同じ顧客の別項目を他の人が更新している場合があります。上書きの影響を項目単位で確認してください。
ロック待ちや重複キーエラーとの違い
保存できないトラブルでも、原因によって確認箇所は変わります。警告のタイトルだけで判断せず、表示された文章と、既存データの修正か新規登録かを確認しましょう。
| 症状 | 主な確認対象 | 最初の対応 |
|---|---|---|
| 変更の競合を知らせる警告 | 同じレコードを更新した別画面・別処理 | 入力を退避し、最新値と比較 |
| 他ユーザーがロック中と表示 | 編集中の担当者や長い処理 | 編集状況を確認して完了を待つ |
| 重複する値があるため登録不可 | 主キー・一意索引・独自採番 | 重複した項目と採番方法を確認 |
| レコードセットは更新できない | クエリやフォームの更新可能性 | 更新元の構成を確認 |
「このレコードセットは更新できません」と表示される場合は、関連記事027で扱う更新可否の問題として切り分けます。警告を消すためだけに設定を一括変更すると、原因が分かりにくくなります。
2 データの競合が出たときに最初に行う対処
最初に行うのは、入力内容の退避です。内容を確認せずに上書き保存や変更の破棄を選ぶと、自分または他の担当者の変更を失うおそれがあります。まず対象のレコードIDと、入力した値を残してください。
入力内容を退避してから選択肢を判断する
警告にクリップボードへのコピーがある場合は、内容を退避する手段として使えます。コピー後は社内で認められた一時保存先へ貼り付け、必要な項目が残っているか確認します。クリップボードの内容は次のコピー操作で置き換わるため、そのまま放置しないでください。
| 選択肢の意味 | 起こること | 判断のポイント |
|---|---|---|
| 保存する Save Record | 自分の変更で他の変更を上書きする可能性がある | どちらの値を採用するか確認できた場合に限る |
| コピーする Copy to Clipboard | 自分の変更を含むレコードをコピーし、他の保存内容を表示する | 貼り付けて退避を確認し、項目ごとに比較する |
| 変更を破棄する Drop Changes | 自分の未保存変更を取り消し、他の保存内容を残す | 自分の入力が不要か、退避済みかを確認する |
上記はMicrosoftが示す選択肢の意味です。日本語のボタン名は利用環境の実画面で確認してください。コピー機能だけに頼れない場合は、画面の記録や管理者への連絡を行い、Accessを強制終了する前に復旧方法を相談します。
最新値と照合して必要な変更だけを反映する
1 レコードID、変更した項目、入力値、警告文を記録する。
2 入力を退避し、退避先で内容を確認する。
3 他の担当者へ編集状況を確認し、対象レコードの最新値を表示する。
4 退避した値と最新値を比較し、採用する値を決める。
5 必要な項目だけを入力し直して保存し、保存後の値を確認する。
退避したレコード全体を貼り戻すと、他の担当者の変更まで元に戻すおそれがあります。例えば住所は先に保存された値を残し、自分が修正した電話番号だけを反映する、といった判断が必要です。再び競合する場合は入力を繰り返さず、更新元を調査します。
3 データの競合が発生する主な原因
原因を探すときは「利用者の人数」だけでなく、「同じレコードを書き換える経路」を確認します。別のフォーム、直接開いたテーブル、ボタンの更新処理などを並べると、一人で使っている場合の競合も整理できます。
複数人で同じレコードを編集している
共有する顧客情報や受注情報を、複数の担当者が同時期に修正すると競合しやすくなります。とくに入力途中の画面を開いたまま、確認の電話や別作業を始めると、保存までに他の更新が入る時間が長くなります。
まず、競合したレコードを誰がどの画面で編集していたかを確認します。部署ごとに別の画面を使っていても、保存先が同じ顧客テーブルであれば更新が重なる可能性があります。
一人で複数のフォームやテーブルを編集している
一人であっても、顧客フォームを編集中に顧客テーブルを直接開いて同じ顧客を修正すれば、二つの更新経路ができます。別フォームで保存された後に、先のフォームから保存しようとして競合する場合があります。「他のユーザー」は必ずしも別の人物とは限りません。
未保存フォームと更新クエリやVBAが重なっている
フォームの入力を保存していない状態で、ボタンから同じレコードを更新するクエリやVBAを実行する構成にも注意が必要です。更新クエリは、条件に合うデータをまとめて書き換える処理です。画面の入力と別処理の変更が食い違うと、その後の保存で競合することがあります。
開発担当者は、ボタンを押した直後だけでなく、画面を閉じるときや、別レコードへ移るときの処理も確認します。タイマー処理や外部バッチが動いている場合も、同じIDを書き換えていないか調べてください。これらは調査候補であり、発生原因は再現条件から確定します。
| 発生タイミング | 原因候補 | 確認する場所 |
|---|---|---|
| 共有利用時に起こる | 他担当者との更新重複 | 同じIDの編集時刻・担当者 |
| 別画面を操作した後に起こる | フォームとテーブルなどの自己競合 | 開いている画面と保存先 |
| 更新ボタンや終了操作で起こる | VBAやクエリとの更新重複 | 保存前後のイベントとSQL |
4 共有利用で競合を減らす運用とロック設定
共有利用では、編集時間を短くし、同じデータを誰が更新するかを整理することが基本です。ロック設定は補助になりますが、変更するだけであらゆる競合が解消するわけではありません。更新の流れと接続先を確認したうえで選びます。
編集から保存までを短くする
・入力に必要な情報をそろえてから編集を始める。
・内容が確定したら保存し、未保存のまま長時間離席しない。
・同じ案件や顧客を複数部署で扱う場合は、担当や更新の順番を決める。
新規登録を全員一人ずつに制限する必要があるとは限りません。新規入力の問題では、既存行の競合と、主キーの重複を区別します。最大値に1を加える独自採番は、二つの処理が同じ番号を取得しないか、開発担当者が確認すべき設計上の論点です。
RecordLocksの3設定と制約
フォームのRecordLocksは、Access側のロック方法を指定するプロパティです。Microsoft Learnでは0が既定値とされています。ただし、既存システムでは設定済みの値を確認してください。
| 設定と値 | 主な動作 | 検討時の注意 |
|---|---|---|
| ロックしない 0 | 編集を許し、保存時の競合を検出する楽観的ロック | 他の更新との照合・再入力が必要になる |
| すべてのレコード 1 | フォームを開いている間、対象全体をロックする | 他利用者の編集・追加・削除を妨げる |
| 編集済みレコード 2 | 編集開始時からロックする悲観的ロック | ページ単位に及ぶ場合があり、常に1件だけとは限らない |
ODBC接続のデータは、このプロパティにかかわらず「ロックしない」と同様に扱われます。SQL Server側の制御とは分けて考えてください。
フロントエンドを分割し担当を整理する
共有構成では、フォームやVBAを持つフロントエンドと、データを持つバックエンドを分け、各利用者にフロントエンドのコピーを配布する方法があります。Microsoftも共有方法として案内しています。ただし、分割しても同じレコードの更新競合は残ります。
OneDriveやSharePointの同期フォルダーに置いたACCDBを、複数人が直接開いて同時編集する運用は避けます。既存構成を変更する前に、バックアップとテスト環境を用意し、共有先・権限・接続方法を管理者と確認してください。
Accessのデータ競合が繰り返し発生する場合は、フォーム・VBA・共有構成をまとめて見直すと、調査の漏れを減らせます。既存Accessの原因調査や改修をご相談いただけます。
5 VBA 更新クエリ SQL Server連携で確認すること
ここからは開発・保守担当者向けの内容です。見直す中心は、フォーム保存と別の更新処理の順序、書き戻し時の競合検出です。警告を隠す処理や無条件の上書きでは、入力消失の原因が残ります。
フォーム保存と別更新の順序を整理する
未保存の入力があるかを調べ、保存が必要なら先に保存を試みます。保存が成功した場合に限って別の更新へ進み、その後に必要なデータを再表示する流れを検討します。保存の失敗やキャンセルがあれば、後続処理へ進めない設計にしてください。
以下は実行用コードではなく、処理順序を示す疑似コードです。基本仕様で候補にしたVBAの保存例は実機検証が未実施のため、この原稿では完成コードとして掲載していません。
① 対象フォームに未保存の入力があるか確認する
② 未保存なら保存を試みる
③ 保存失敗またはキャンセルなら処理を中止して利用者に知らせる
④ 保存成功を確認して別の更新を実行する
⑤ 別更新の結果を確認し、必要な範囲を再表示する
フォーム保存と別更新を順に行っても、間に他ユーザーの更新が入る可能性は残ります。業務上まとめて成功させる必要がある処理は、トランザクションの範囲や更新条件も設計します。先の保存だけが完了した場合の表示や復旧方法も決めておきましょう。
イベントの再実行と再表示の違いに注意する
フォームの更新前イベントから安易に再保存を呼ぶと、同じ処理への再入や意図しない更新につながりかねません。どのイベントが、どのレコードを、どの順に更新するかを整理します。エラーを無視して後続の更新を続ける設計も避けてください。
| 方法 | 用途 | 注意点 |
|---|---|---|
| Refresh | 現在のレコード集合にある変更を反映 | 追加・削除や抽出条件の変化を全面的には反映しない |
| Requery | 元の問い合わせを実行し直す | 追加・削除や抽出条件の変化を反映する |
どちらも、自分と他の人の変更を自動で正しく統合する機能ではありません。未保存データの扱いを決めてから呼び出します。Requeryの後に同じ行を表示したい場合は、対象IDを使った位置の復元なども検討します。
5-2 一時テーブルとODBC連携
一時テーブルの書き戻しにも競合検出が必要
ローカルの一時テーブルで編集し、確定時に共有データへ反映する方法は、画面編集中の直接更新を減らせます。ただし、編集している間に共有側のデータが変わることはあります。最後に無条件で書き戻すと、他の変更を失う問題は残ります。
設計では、読み込み時点の版情報を保持し、書き戻す時点でも同じ版かを確認します。照合と更新を別々の処理にすると、その間に別の変更が入るため、更新条件そのものへ版情報を含める考え方が必要です。
書き戻しの疑似手順：主キーと読込時の版が一致する行だけを更新する。更新件数が1件なら成功とする。0件なら変更済み・削除済みなどを確認し、再取得して利用者に判断を求める。複数件の更新になれば、キーや条件を見直す。
版による検出は、対象データを更新する全経路が同じ仕組みに従っていることが前提です。Access側で独自の版番号を管理するなら、直接編集や外部バッチも含めて管理します。一部の更新だけ版番号を変えない構成では、検出が漏れる可能性があります。
ODBCとrowversionの役割
ODBCは、AccessからSQL Serverなどのデータベースへ接続する仕組みです。連携後に競合が起きる場合は、フォーム以外の更新元やリンクテーブルの識別情報も含めて調査します。次の項目は確認候補であり、該当するだけで原因が確定するわけではありません。
・リンク先の主キーや一意な行識別が正しく認識されているか。
・トリガーや別アプリ、外部バッチが保存対象を変更していないか。
・テーブル構造の変更後にリンク情報の再確認が必要ではないか。
・ODBCドライバー、Access、SQL Serverの版と発生条件を記録できているか。
SQL Serverのrowversionは、行の変更を検出するために利用できる自動生成のバイナリ値で、日時ではありません。読込時の値を更新条件に含めることで、途中で別の更新があったかを判定できます。追加するだけで、あらゆる競合がなくなるわけではありません。
競合検出で更新が止まったときに、最新値を示すか、入力を退避して再編集させるかまで設計する必要があります。また、複数行をまとめて反映する業務では、一部成功のまま残さないかなど、処理全体の整合性も確認します。
6 解決しないときの確認リストと相談の目安
再発する場合は、発生条件と更新経路を記録して管理者へ渡します。「時々保存できない」だけでは再現が難しいため、どのレコードに対して、どの操作をしたときに警告が出るかを具体化しましょう。
再現条件と更新経路を記録する
| 記録項目 | 記録する内容の例 |
|---|---|
| 発生時刻と対象 | 発生日時、顧客ID・受注番号などの識別子 |
| 画面と操作 | フォーム名、押したボタン、直前に開いた別画面 |
| 警告と結果 | 警告文全体、選んだ操作、入力値が残ったか |
| 利用構成 | 利用人数、フロントエンドの配布方法、データ保存先 |
| 環境と処理 | Accessの製品名・ビルド・bit数、VBA・バッチの有無 |
管理者は、同じレコードIDを軸に、画面操作・イベント・更新SQL・外部処理の時刻を並べます。顧客データの全文をむやみに記録するのではなく、調査に必要な識別子と変更項目を中心に、社内の情報管理ルールに沿って残してください。
Access改修とデータベース移行を判断する
特定ボタンの後にだけ起きるなら、更新順序の改修で改善できる可能性があります。一方、複数アプリから頻繁に同じデータを更新しているなら、データの管理方式や処理の責任分担まで見直す必要があります。
| 担当 | まず行う対応 |
|---|---|
| 入力担当者 | 入力の退避、最新値との照合、発生条件の記録 |
| 開発・保守担当者 | イベント・SQLの更新順序、ロック設定、競合検出の調査 |
| システム管理者 | 共有構成、バックアップ、改修範囲・移行方針の判断 |
Accessの画面を残し、データだけをSQL ServerやAzure SQL Databaseへ移す選択肢もあります。ただし、移行しても同じ行への更新はぶつかります。利用人数だけで決めず、接続環境、応答速度、運用体制、予算を踏まえて判断してください。
ロックファイルの削除、全件ロック、通常業務での排他起動を、競合の一律の解決策にはしません。保守作業で排他利用が必要な場合は、利用者の終了とバックアップを確認してから行います。下記の関連記事も併せて参照してください。
まとめ
Accessのデータの競合では、同じレコードに対する更新がどこで重なるかを調べることが大切です。別の利用者だけでなく、自分が開いた別フォームやVBAも更新元になります。警告が出たら入力を退避し、最新値と比較して必要な変更だけを反映してください。
再発防止では、編集時間の短縮、担当の整理、保存と更新の順序を見直します。一時テーブルやSQL Serverを使う場合も、書き戻し時の競合検出と、競合後に利用者が判断できる仕組みが必要です。
Accessのデータ競合で業務が止まる場合はご相談ください
毎日競合が起きる、入力内容が失われる、複数の更新処理があり原因を追えない場合は、既存システム全体の調査が必要です。インフォースでは、フォーム・VBA・共有構成を調べ、更新が重なる箇所を整理します。既存Accessの改修から、画面を残したSQL Serverへの移行まで、業務に合う改善方法をご相談いただけます。
よくある質問
一人で使っているのに競合するのはなぜですか
別フォーム、テーブルの直接編集、更新クエリやVBAが同じレコードを書き換えている可能性があります。人数だけでなく、開いている画面と実行される処理を確認してください。
他の変更を上書きする可能性があるため、内容を確認せずに選ぶのは避けます。自分の入力を退避し、最新データと比較して採用する値を決めてください。
必ず直るとは限りません。更新が重なる原因や接続方式によって対応が変わります。ODBCのデータにはRecordLocksの設定がそのまま適用されない点にも注意してください。
一律に制限する必要はありません。新規登録で問題がある場合は、警告文を確認し、主キーの重複や独自採番の衝突など、既存レコードの更新競合とは別の問題も調べます。
同じレコードを複数の処理が更新すれば、移行後も競合は起きます。競合を検出する条件と、最新データの確認・再入力を行う手順を設計する必要があります。
参考情報
競合の原因と警告の3選択肢
https://support.microsoft.com/en-us/access/write-conflict-dialog-box
ロック設定、既定値、ページ単位の注意、ODBCの制約
https://learn.microsoft.com/en-us/office/vba/api/access.form.recordlocks
分割構成と共有方法、OneDrive・SharePointへの注意
https://support.microsoft.com/en-us/access/ways-to-share-an-access-desktop-database
版による変更検出と条件付き更新
https://learn.microsoft.com/en-us/sql/t-sql/data-types/rowversion-transact-sql
現在のレコード集合の更新
https://learn.microsoft.com/en-us/office/vba/api/access.form.refresh
再問い合わせとRefreshとの違い
https://learn.microsoft.com/en-us/office/vba/api/access.form.requery