Access VBAのクエリ実行とDoCmd・DAOの考え方
Accessを使った業務システムでは、
「VBAからクエリを実行する」という場面が必ず出てきます。
その際に登場するのが、
- DoCmd
- DAO
という2つの手段です。
ネット上では
「DoCmdとDAOの違い」
「どちらが速いか」
といった比較が多く見られますが、
実務で本当に重要なのは 優劣ではなく役割の違い です。
この記事では、
Access VBAにおけるクエリ実行を
設計・保守の視点から整理します。
Access VBAで「クエリを実行する」とはどういうことか
クエリ実行＝SQLを流すことではない
「クエリを実行する」という言葉から、
単純に「SQLを流すこと」を想像されがちですが、
Accessでは少し意味が異なります。
Accessのクエリは、
- SQLそのもの
- クエリオブジェクト（保存された定義）
という2つの側面を持っています。
つまり、
- クエリを“操作として実行する”
- SQLを“処理として実行する”
この2つは、
似ているようで中身が違います。
DoCmdとDAOの違いは、
この考え方の違いをそのまま反映しています。
なぜVBAからクエリを実行するのか
VBAからクエリを実行する目的は、主に次の3つです。
- 人の操作を介さずに処理したい
- 実行順や条件を制御したい
- 同じ処理を何度も再現したい
単に「実行できるからVBAを使う」のではなく、
制御と再現性を得るためにVBAを使います。
この前提を押さえないまま
DoCmdとDAOを使い分けると、
後々の保守で必ず苦労します。
DoCmdとDAOは何が違うのか
DoCmdは「Access操作の自動化」
DoCmdは、
人がAccessを操作する行為をVBAで代行する仕組みです。
- クエリを開く
- 実行する
- フォームを操作する
こうした
「Accessの画面操作」を前提にしています。
言い換えると、
DoCmdは Accessらしい方法 です。
DAOは「データベース操作」
一方、DAOは
データベースそのものを操作するための仕組みです。
- SQLを直接実行する
- レコードを操作する
- トランザクションを管理する
AccessというUIを意識せず、
データ処理そのものに集中します。
DAOは、
Accessの中にある「DBエンジン寄りの存在」
と考えると分かりやすいでしょう。
DoCmdでクエリを実行する考え方
DoCmd.OpenQuery / RunSQL の意味
DoCmdでクエリを実行する場合、
- OpenQuery
- RunSQL
といった命令を使います。
これらは、
保存されたクエリを呼び出す
という考え方です。
SQLを直接書くというより、
「Accessに登録されている処理を実行する」
という位置づけになります。
DoCmdを使うメリット・制約
DoCmdのメリットは明確です。
- 記述が簡単
- Accessの構造が分かりやすい
- 画面操作と連動しやすい
一方で、制約もあります。
- 細かいエラー制御がしづらい
- 実行結果を扱いにくい
- 処理の途中制御が弱い
DoCmdは、
**「操作を自動化したいとき」**に向いています。
DAOでクエリを実行する考え方
DAO.Executeがやっていること
DAO.Executeは、
SQLを直接データベースに投げて実行する命令です。
- クエリオブジェクトを介さない
- 画面操作を伴わない
純粋に
「データ処理としてSQLを実行する」
という動きになります。
そのため、
処理結果やエラーを
プログラム側で細かく制御できます。
DAOを使うメリット・注意点
DAOのメリットは、
- 制御性が高い
- エラー処理が明確
- トランザクション管理が可能
といった点です。
一方で、
- 書き方が難しくなりやすい
- SQLがVBA内に散らばりやすい
という注意点もあります。
DAOは、
設計と保守を意識して使う必要がある道具です。
DoCmdとDAOの使い分けで起きやすい誤解
「どちらでも動くから同じ」という誤解
DoCmdでもDAOでも、
結果として「動く」ケースは多くあります。
しかし、
- 動く
- 正しく設計されている
は別物です。
処理が複雑になるほど、
この差は後から大きく効いてきます。
処理をVBAに寄せすぎる危険性
DAOを多用しすぎると、
- SQLがVBAに埋もれる
- クエリ定義が見えなくなる
- 他の人が理解できなくなる
という状態に陥りがちです。
VBAは万能ですが、
万能に使うべきではありません。
実務での使い分けの判断基準
DoCmdを選ぶべきケース
次のような場合は、
DoCmdが適しています。
- 単純な追加・更新処理
- 画面操作と連動した処理
- Accessの構造をそのまま使いたい場合
「誰が見ても分かる」ことが重要な場面です。
DAOを選ぶべきケース
次のような場合は、
DAOを選ぶ方が安全です。
- 更新・削除を厳密に管理したい
- エラー時の処理を制御したい
- 処理結果を判断材料に使いたい
処理としての正確さが求められる場面です。
クエリ・VBA・設計のバランス
クエリは「処理の定義」
クエリは、
- 何をする処理なのか
- どんなデータを扱うのか
を明示するためのものです。
可視性と再利用性を持たせる役割があります。
VBAは「制御と判断」
VBAは、
- 実行順を決める
- 条件で分岐する
- 例外を処理する
ためのものです。
処理そのものを
すべてVBAに押し込むのではなく、
役割を分けることが重要です。
まとめ｜DoCmdとDAOは「優劣」ではなく「役割分担」
DoCmdとDAOは、
- どちらが上
- どちらが正解
という関係ではありません。
- Accessらしい操作を自動化するのがDoCmd
- データ処理を制御するのがDAO
という 役割分担 です。
システムキューブの「Accessの移行変換、mdb・adpのバージョンアップ」について
