Accessの削除クエリとVBA実行の考え方
Accessを業務で使っていると、
必ず一度は「削除」という処理に向き合うことになります。
追加や更新と違い、
削除は一度実行すると元に戻せない処理です。
その削除を、さらにVBAから自動実行するとなると、
設計者にはより重い責任が発生します。
この記事では、
- Accessの削除クエリとは何か
- それをVBAから実行するとはどういう意味か
- DoCmdとDAOをどう考えて使い分けるべきか
を、実務と設計の視点から整理します。
Accessにおける「削除」という処理の重さ
削除は「元に戻せない処理」である
Accessに限らず、
業務システムにおける削除は特別な処理です。
- 追加はやり直せる
- 更新は修正できる
- しかし削除は「存在そのものを消す」
という決定的な違いがあります。
特にAccessは、
- ロールバック機構が弱い
- 操作が比較的簡単
- 個人や部門単位で運用される
という特徴があるため、
削除事故が起きやすい環境でもあります。
なぜ削除処理は慎重に設計すべきなのか
削除処理の事故は、
多くの場合「悪意」ではなく、
- 条件の指定ミス
- 想定外のデータ増加
- テストと本番の差
といった設計上の甘さから起きます。
特にVBAから削除を実行すると、
人の確認を介さず処理が進むため、
影響範囲は一気に広がります。
Accessの削除クエリとは何か
削除クエリの基本的な役割
Accessの削除クエリは、
- 条件に一致したレコードを
- テーブルから物理的に削除する
ためのクエリです。
SELECTクエリと同じように見えても、
実行された瞬間にデータが消える
という点が決定的に違います。
SELECTクエリとの決定的な違い
削除クエリは、
- プレビューはできる
- だが実行すると結果が残らない
という特徴があります。
SELECTクエリで
「ちゃんと絞れているから大丈夫」
と判断しても、
実行時には想定外の条件が含まれていることもあります。
この「確認できたつもり」になりやすい点が、
削除クエリの怖さです。
削除クエリをVBAから実行するということ
なぜVBAから削除クエリを実行するのか
削除クエリをVBAから実行する理由は、
- 実行タイミングを制御したい
- 条件を動的に変えたい
- ユーザー操作と処理を分離したい
といった、システム化の要請です。
ここで重要なのは、
削除が「人の操作」から
「システムの判断」へ移るという点です。
クエリ単体実行との考え方の違い
手動で削除クエリを実行する場合、
実行者は結果を目視で確認できます。
しかしVBA実行では、
- 実行者が意識しない
- 条件が見えにくい
- 実行結果を確認しない
という状態になりがちです。
つまり、
削除の責任が人から設計へ移る
ということになります。
DoCmdで削除クエリを実行する考え方
DoCmd.OpenQuery / RunSQLの位置づけ
DoCmdを使った削除は、
- 保存された削除クエリを
- Accessの操作として実行する
という考え方です。
Accessの画面操作を
VBAで自動化しているイメージに近く、
比較的Accessらしい方法です。
DoCmd実行で起きやすい問題
DoCmdによる削除では、
- 確認メッセージが出る
- 出ない設定にすると逆に危険
- 削除件数を正確に把握しにくい
といった問題が起きやすくなります。
「実行できたかどうか」以上の
判断がしづらい点が弱点です。
DAOで削除処理を実行する考え方
DAO.Executeによる削除処理の特徴
DAO.Executeを使うと、
- SQLを直接実行
- 画面を介さず処理
- 削除件数を取得可能
といった、
制御された削除処理が可能になります。
削除を「処理」として
扱いたい場合はこちらが適しています。
DAO削除で注意すべき点
DAOは強力ですが、
その分リスクも高まります。
- 条件ミス＝即全件削除
- ユーザーの目に触れない
- ログがなければ原因追跡不能
DAOで削除を行う場合は、
- 条件の明示
- 実行前チェック
- ログやバックアップ
が前提になります。
削除クエリとVBA実行で起きやすい設計ミス
条件をVBAに寄せすぎる問題
削除条件をすべてVBAで組み立てると、
- SQLが読めなくなる
- クエリ定義が消える
- 属人化が進む
という状態になります。
結果として、
誰も触れない削除処理が出来上がります。
「動いたからOK」という判断の危険性
削除処理は、
- 一度成功すると
- 次も大丈夫だと思いがち
ですが、
データ量や条件は必ず変化します。
「一度動いた」は、
安全の証明にはなりません。
実務での削除処理の判断基準
削除クエリを使うべきケース
削除クエリが適しているのは、
- 一時テーブル
- 明確に不要な中間データ
- 復元不要な処理結果
など、
業務的に価値がないデータに限られます。
削除以外を検討すべきケース
業務データの場合は、
- 論理削除（フラグ管理）
- 履歴テーブルへの退避
- ステータス変更
といった方法を
まず検討すべきです。
「消さない設計」は、
後で必ず助けになります。
クエリ・VBA・業務設計のバランス
削除は「技術」ではなく「業務判断」
技術的に削除できることと、
業務的に削除してよいことは別です。
- 誰が判断したのか
- どこまで影響するのか
- 後から説明できるか
ここまで考えて、
初めて削除処理になります。
長く使えるAccessに必要な考え方
長く使われるAccessシステムは、
- 削除を怖がる
- 消さなくて済む設計を選ぶ
- 説明できる処理を持つ
という特徴があります。
削除クエリとVBA実行は、
Access設計の成熟度が最も出る部分です。
まとめ｜削除クエリはVBA実行時こそ慎重に
削除クエリは便利ですが、
同時に最も危険な処理です。
- VBA実行は人の目を外す
- だからこそ設計が重要
- 削除は最後の手段
システムキューブの「Accessの移行変換、mdb・adpのバージョンアップ」について
