概要
| この記事の結論 Accessのアクションクエリの確認メッセージは、オプション設定やSetWarningsで非表示にできます。ただし、確認を省くと誤更新を見逃しやすくなります。特定の処理だけを自動化する場合は、警告設定を変えずに実行できるDAOのExecuteも選択肢です。この記事では設定の違い、エラー時の戻し方、対象件数の確認、処理後の照合まで説明します。 |
この記事でわかること
- 確認を消す前に変更範囲を決める
- Accessのオプションで確認を非表示にする
- マクロとVBAで必要な処理だけ制御する
- DAOで警告設定を変えずに実行する
- 誤更新と再実行を防ぐ実務チェック
この記事の主な内容
- 確認を消す前に変更範囲を決める
- Accessのオプションで確認を非表示にする
- マクロとVBAで必要な処理だけ制御する
- DAOで警告設定を変えずに実行する
- 誤更新と再実行を防ぐ実務チェック
- メッセージが消えない場合と元に戻す方法
- よくある質問
想定読了時間：約12分～15分
確認を消す前に変更範囲を決める
アクションクエリの確認は、Accessのオプション、マクロの警告メッセージ設定、VBAのSetWarningsで制御できます。自動処理を作る場合は、警告設定を変更せずにDAOのExecuteで実行する方法もあります。最初に「手作業全般で消したいのか」「このボタンの処理だけで消したいのか」を決めましょう。
アクションクエリとは、テーブルへの追加・更新・削除・テーブル作成を行うクエリです。選択クエリのように表示するだけではなく、データやテーブルの状態を変えます。確認画面を省略しても、処理の影響が小さくなるわけではありません。
確認メッセージとエラーは別のもの
「これから更新しますか」という確認と、「型が一致しない」「必要な値がない」というエラーは分けて考えます。さらに、パラメーターの入力、マクロのセキュリティ通知、自作のMsgBoxも別です。警告設定を変えれば画面上の通知がすべて消える、という理解は避けてください。
例えば、月次処理で処理済みフラグを更新するとき、毎回同じ確認が続くなら自動化の余地があります。一方、担当者が条件を毎回組み替える削除クエリでは、最後の確認が誤操作に気づく機会になります。まず対象IDや件数を確認できる仕組みを用意します。
| 方法 | 向いている用途 | 注意する範囲 |
|---|---|---|
| Accessのオプション | 自分の作業環境で確認表示を変更する | そのクエリだけに限定する設定ではない |
| マクロ／SetWarnings | 既存のOpenQueryなどを一時的に制御する | 復帰処理と異常終了を考える |
| DAO Execute | VBAから追加・更新・削除を制御する | エラー処理と結果件数を自分で確認する |
この表の方法に優劣があるというより、責任範囲が異なります。初心者が一度だけ手作業するなら確認を残し、定例処理を作るなら対象確認と結果記録まで一緒に設計すると判断しやすくなります。
Accessのオプションで確認を非表示にする
継続して確認を省略する場合は、Accessのオプションでアクションクエリの確認設定を変更します。既存システムの運用担当者が決めた設定がある場合は、それに合わせてください。設定は元に戻せるよう、変更前の状態を控えておきます。
1. Accessで［ファイル］を開き、［オプション］を選びます。
2. ［クライアントの設定］を開きます。
3. ［編集］付近の［確認］にある［アクション クエリ］のチェックを外します。
4. ［OK］で確定し、コピーしたデータベースの小さな更新処理で確認します。
バージョンや表示言語によって項目名・配置が異なる場合があります。［レコードの変更］や［ドキュメントの削除］など別項目までまとめて外す必要はありません。今回変更したいのは、アクションクエリの確認です。
設定の影響はクエリ単位ではない
この設定は、保存したクエリに付ける「確認なし」の属性ではありません。同じAccess環境で別のアクションクエリを実行する場面にも関係します。そのため、利用者へ配布する処理を各PCの設定だけに依存させると、PCによって挙動が違う原因になります。
戻すときは同じ画面でチェックを付け直します。アプリケーション全体の挙動を変更する必要がないなら、次の方法で対象処理を限定する方が管理しやすいでしょう。設定変更だけでは、更新対象や条件の正しさは検査されません。
マクロとVBAで必要な処理だけ制御する
既存のボタン処理でDoCmd.OpenQueryを使っている場合は、実行前にSetWarnings False、終了時にSetWarnings Trueを実行する構成にできます。ただし、正常終了する3行だけを書いて終わりにせず、エラーが起きた経路でも警告を戻します。
マクロで設定する場合
マクロでは［警告メッセージの設定］に相当するアクションで表示を［いいえ］にし、クエリを開くアクションを実行した後に［はい］へ戻す流れにします。アクションが見当たらない場合は、すべてのアクションの表示や信頼設定を確認します。内容不明のファイルを一律に信頼する操作はしないでください。
マクロアクションの警告設定は、マクロ終了時の復帰動作がMicrosoftの資料に説明されています。一方、VBAのSetWarningsでは、明示的にTrueへ戻す設計が必要です。両者を同じ後処理だと考えず、実装する方式に合わせます。
VBAでは終了経路を一か所へ集める
次は、パラメーターのない保存済み更新クエリ「Q_処理済更新」を呼ぶ例です。標準モジュールへ置き、クエリ名は実際の名前に変更します。このプロシージャが警告状態を管理し、開始時は通常の警告有効状態である前提です。別の処理が警告を制御している途中から重ねて呼ばないようにします。
Public Sub RunSavedAction()
Dim errNumber As Long
Dim errText As String
On Error GoTo ErrorHandler
DoCmd.SetWarnings False
DoCmd.OpenQuery “Q_処理済更新”, acViewNormal, acEdit
ExitHandler:
DoCmd.SetWarnings True
If errNumber <> 0 Then
MsgBox “処理を確認してください。” & vbCrLf & _
errNumber & “: ” & errText, vbExclamation
End If
Exit Sub
ErrorHandler:
errNumber = Err.Number
errText = Err.Description
Resume ExitHandler
End Sub
エラー番号と内容を控えた後、復帰処理へ移動します。開発中にVBEの［終了］やリセットで強制停止した場合、通常のエラー処理が最後まで動くとは限りません。「エラー処理を入れたから絶対に戻る」とは考えず、停止後の警告状態を確認してください。
また、SetWarnings Falseは対象クエリの条件を検査する命令ではありません。更新漏れや除外が発生したかを、警告を消した状態だけで判断するのも不十分です。自動実行の新規設計では、次のDAO方式も検討できます。
アクションクエリの自動化と誤更新対策で迷ったときは
まずは記事の手順で対象と結果を確認しましょう。既存の処理との関係が分からない、変更の影響を判断できない場合は、現在のテーブル・クエリ構成と困っている点を整理して、Accessの教科書へご相談ください。
DAOで警告設定を変えずに実行する
DAOは、AccessのデータベースをVBAから扱うための仕組みです。QueryDefのExecuteを使うと、保存したアクションクエリをAccessの確認画面に頼らず実行できます。警告のオン・オフを変更しないため、戻し忘れを避けやすいのが利点です。
先に型を指定した更新クエリを保存する
例では「T_処理対象」に数値型の［対象ID］とYes/No型の［処理済］があるとします。次のSQLを「Q_処理済更新_指定ID」として保存します。対象IDは主キーなどで重複しない設計にしておくと、対象を1件へ限定できます。これは架空の説明用テーブルです。
PARAMETERS pID Long;
UPDATE [T_処理対象]
SET [処理済] = True
WHERE [対象ID] = [pID]
AND [処理済] = False;
最後の条件によって、すでに処理済みの行を対象外にしています。例えばID101が未処理なら1件、ID101が処理済みなら0件、ID101が存在しなくても0件になります。同じ0件でも意味が違うため、対象レコードの存在と状態は別途確認します。
実行後の件数を同じオブジェクトから取得する
次のコードはDAO参照設定が利用できるAccess VBAを前提にしています。「ユーザー定義型は定義されていません」と表示される場合は参照設定を確認します。パラメーターは文字列連結でSQLへ埋め込まず、型を持った値として渡します。
Public Sub MarkProcessed(ByVal targetID As Long)
Dim db As DAO.Database
Dim qd As DAO.QueryDef
On Error GoTo ErrorHandler
Set db = CurrentDb
Set qd = db.QueryDefs(“Q_処理済更新_指定ID”)
qd.Parameters(“pID”).Value = targetID
qd.Execute dbFailOnError
MsgBox “更新件数: ” & qd.RecordsAffected, vbInformation
ExitHandler:
Set qd = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox Err.Number & “: ” & Err.Description, vbExclamation
Resume ExitHandler
End Sub
このMsgBoxは、確認画面とは別にコード側で出している結果通知です。無人処理では、対話を待たないログ記録に置き換えます。RecordsAffectedは実行に使ったQueryDefから取得し、対象ID・日時・件数・成否をまとめて残すと、後から調査しやすくなります。
dbFailOnErrorは、失敗を正常扱いしないために指定します。ただし、複数のExecuteをまとめて一つの業務処理として取り消すには、対応するデータソースでトランザクションを別途設計する必要があります。接続先がSQL Server等の場合も含め、バックアップや復旧方法の代わりにはなりません。
誤更新と再実行を防ぐ実務チェック
確認を省略するなら、処理前後の照合が重要になります。特にWHERE条件の抜け、結合先の違い、再実行での二重追加は、画面を非表示にしても防げません。処理をコピーで試し、予想した件数と実際の状態が一致してから本番へ反映します。
| タイミング | 確認する内容 | 例 |
|---|---|---|
| 実行前 | 同じ条件の選択クエリでIDと件数を見る | 対象ID101だけが抽出される |
| 実行前 | 実データの保存先をバックアップする | 分割DBならバックエンドも対象 |
| 実行直後 | 更新件数と対象レコードの値を確認する | 1件更新、処理済がTrue |
| 例外時 | 0件・エラー・想定超過を区別する | すでに処理済みか、IDがないか |
| 再実行前 | 同じ処理を繰り返してよいか確認する | 追加済みなら再追加しない |
選択クエリで数えた後に、別の利用者がデータを変更することもあります。そのため、事前確認の件数は実行時点の結果を保証しません。同時利用がある場合は、状態条件、重複制約、処理単位の管理などを組み合わせます。
二度押しと再実行で結果が変わる処理に注意
「処理済をTrueにする」更新と、「残高に100を加える」更新では、再実行の影響が違います。後者は繰り返すたびに値が増えます。追加クエリも同じデータを二度入れる可能性があるため、単にボタンを一時的に押せなくするだけで十分とは限りません。
業務キーに重複を許さない制約を設ける、処理IDを記録する、追加済みの行を除外するなど、データ側でも二重処理を防ぎます。途中で通信が切れたときは、処理が完了したかをログと保存結果で確認し、結果が不明なまま実行し直さない運用が必要です。
メッセージが消えない場合と元に戻す方法
消えないときは、まず表示された文言を読み、確認・エラー・入力要求・独自通知のどれかを判定します。設定を追加で無効化するより、通知の発生元を特定した方が解決に近づきます。画面名と実行したボタン、クエリ名を控えると調べやすくなります。
| 症状 | 主な確認先 | 対処の方向 |
|---|---|---|
| 値の入力画面が出る | パラメーターとフィールド名 | 未指定値や名前の誤りを直す |
| 独自の確認が残る | VBAのMsgBox／マクロ | 業務上必要な確認か判断する |
| エラーが出る | SQL・型・権限・参照先 | 原因を直し、エラーを隠さない |
| 別の処理でも確認が消えた | オプション／SetWarnings | 設定を元に戻し影響を確認する |
| ボタンが動かない | 信頼状態・イベント設定 | 実行が許可されているか確認する |
VBAの警告を復帰させたい場合は、信頼できる自分のデータベースでVBEのイミディエイトウィンドウからDoCmd.SetWarnings Trueを実行できます。オプション側のチェックを外していた場合は、その設定も戻します。何を変更したかに合わせて復旧してください。
まとめ
確認メッセージを非表示にする操作は簡単ですが、安全な自動化には対象条件と結果確認が必要です。手作業の確認を残す場面、既存処理で一時制御する場面、DAOで実行する場面を分けましょう。小さなサンプルで正常・0件・エラー・再実行を確かめると、見落としを減らせます。
よくある質問
すべてのエラーや入力画面が消えるわけではありません。実行前の確認、型不一致などのエラー、パラメーターの入力、自作のMsgBoxは別の仕組みです。ただし、警告を非表示にした結果、確認できる情報が減る場面はあります。自動処理では「画面が出なかったから成功」と判断せず、エラー処理に加えて更新件数と保存結果を確認してください。消えない画面があれば、まず文言と発生元を特定します。
オプションの変更は、そのクエリだけに付く設定ではありません。特定のボタン処理に限定するなら、実行前後をSetWarningsで制御するか、DAOのExecuteを使います。ただしSetWarningsも、指定したクエリだけの属性を変えるわけではなく、有効期間中の警告状態を変えます。エラー時にも戻す処理を用意し、別の処理と重ねて使わないようにしてください。新しく組む場合は、対象と件数を扱いやすいDAOも検討できます。
VBAで警告を無効にした後、Trueへ戻す処理を通らずに停止すると、その後の操作でも警告が出ない状態が続く可能性があります。正常終了とエラー終了を共通の後処理へ集めることが基本です。ただしVBEのリセットや強制終了では後処理が実行されないことがあります。開発中に停止した場合は、DoCmd.SetWarnings Trueで戻し、オプションの設定も確認します。処理を再実行する前に、前回の更新結果も調べてください。
実行できます。保存クエリのPARAMETERSで型を宣言し、QueryDefのParametersへ値を設定してからExecuteを呼びます。フォームの値を参照するクエリをそのままDAOで実行しても、期待どおりに自動解決されるとは限りません。まず必要な値を明示的に渡す形へ整理すると分かりやすくなります。パラメーター名、型、Nullの扱いを確認し、値が未設定の場合は実行前に止める入力チェックも用意しましょう。
条件に一致するレコードがない場合は、SQLが正常に実行されても更新件数が0件になることがあります。存在しないID、すでに処理済みの状態、期間条件の間違いなどが考えられます。0件を成功・警告・異常のどれと扱うかは業務ルールで決めます。毎回1件更新する処理なら0件を調査対象にし、未処理分がなければ何もしない処理なら正常扱いにできます。件数だけでなく対象IDと条件もログに残すと判断が容易です。
クエリファイルを配布しただけで、別PCのAccessオプションが同じになると考えないでください。利用者ごとの環境や設定によって確認の出方が違う可能性があります。配布するアプリで挙動をそろえたい場合は、処理側で確認と結果通知を設計し、配布先でも動作を確かめます。製品版AccessとRuntime、マクロの信頼状態、外部データへの権限も確認対象です。手元のPCだけで動いたことを配布完了の条件にしないようにしましょう。
更新・追加・削除クエリの実行結果は、通常の編集操作のように［元に戻す］だけで復旧できると考えないでください。復旧が必要になったときは、バックアップや更新前の記録、処理設計に応じた復元手順を使います。複数の処理をまとめて確定する場合はトランザクションも検討しますが、確定後の履歴保存を自動で代替するものではありません。確認を非表示にする前に、何を保存し、誰がどの方法で戻すかを決めておくことが大切です。
関連記事
アクションクエリの自動化と誤更新対策で迷ったときは
まずは記事の手順で対象と結果を確認しましょう。既存の処理との関係が分からない、変更の影響を判断できない場合は、現在のテーブル・クエリ構成と困っている点を整理して、Accessの教科書へご相談ください。
参考情報
DoCmd.SetWarnings
https://learn.microsoft.com/ja-jp/office/vba/api/access.docmd.setwarnings
QueryDef.Execute
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/querydef-execute-method-dao
SetWarningsマクロアクション
https://support.microsoft.com/en-us/access/setwarnings-macro-action
アクションクエリの確認表示の切り替え
https://support.microsoft.com/en-us/access/turn-delete-object-and-action-query-confirmation-messages-on-or-off