Access VBAでSQLを実行する方法｜RunSQL・DAO.Executeの実務的な使い分け
Accessを業務で使っていると、VBAからSQLを実行する場面は必ず出てきます。
データの一括更新、取込処理、ボタン操作による登録や削除など、VBAとSQLの組み合わせはAccess開発の中核とも言えます。
一方で、
- とりあえず動くコードを書いたまま放置されている
- RunSQLとDAO.Executeの違いを意識せず使っている
- 将来の改修やバージョンアップ時に手が付けられなくなる
といったケースも少なくありません。
この記事では、Access VBAでSQLを実行する代表的な方法を整理したうえで、
実務でどちらを選ぶべきか、なぜそう判断すべきかを、運用・保守の視点から解説します。
Access VBAでSQLを実行するとはどういうことか
AccessでSQLを「VBAから実行する」場面とは
Accessでは、SQLは通常「クエリ」として保存して使います。
しかし、業務システムでは次のような場面で VBAから直接SQLを実行することが多くなります。
- フォームのボタンを押したときにデータを更新する
- 条件に応じてSQLの内容を動的に変えたい
- 大量データを一括でINSERT / UPDATE / DELETEしたい
- 定期処理や疑似バッチ処理を行いたい
こうした場面では、
「保存クエリを実行する」よりも
VBA内でSQLを組み立てて実行する方が都合が良いケースが増えていきます。
保存クエリとVBA直書きSQLの違い
保存クエリは、
- 目で見て確認しやすい
- Access初心者にも分かりやすい
というメリットがあります。
一方で、
- 条件分岐が増える
- 処理パターンが増える
- 業務が複雑化する
といった状況になると、
VBA直書きSQLの方が管理しやすいケースも出てきます。
問題は、「便利だから」という理由だけでVBA直書きSQLが増え、
実装方針が整理されないままシステムが成長してしまうことです。
Access VBAでSQLを実行する代表的な方法
Access VBAからSQLを実行する方法はいくつかありますが、
実務でよく使われるのは次の2つです。
DoCmd.RunSQLとは
DoCmd.RunSQL は、
Accessが用意している アクションクエリ実行用のメソッドです。
DoCmd.RunSQL "UPDATE テーブル名 SET フィールド = 値"
主な特徴は以下の通りです。
- INSERT / UPDATE / DELETE などのアクションクエリ向き
- 実行時に「○件更新しました」というメッセージが出る
DoCmd.SetWarnings Falseでメッセージ抑制が必要
Accessを触り始めた頃に、最初に覚える人も多い方法でしょう。
DAO.Executeとは
DAO.Execute は、
DAO（Data Access Objects）を使ってSQLを実行する方法です。
CurrentDb.Execute "UPDATE テーブル名 SET フィールド = 値", dbFailOnError
こちらは、より業務向け・システム向けの実装になります。
- メッセージ表示が出ない
- エラー制御が明確
- トランザクション処理と相性が良い
一見すると少し難しそうに見えますが、
安定運用を考えると避けて通れない方法でもあります。
RunSQLとDAO.Executeの違いを整理する
機能・挙動の違い
両者の違いを、実務目線で整理すると次のようになります。
| 観点 | RunSQL | DAO.Execute |
|---|---|---|
| メッセージ表示 | 出る（抑制が必要） | 出ない |
| エラー制御 | 曖昧になりやすい | 明確 |
| トランザクション | 扱いにくい | 扱いやすい |
| 小規模処理 | 向いている | 可能 |
| 業務システム | △ | ◎ |
「動く」と「安全に運用できる」は別
RunSQLは「簡単に動く」反面、
処理の結果や失敗をどう扱うかが曖昧になりがちです。
テスト環境では問題なくても、
- データ量が増えた
- 同時操作が増えた
- 想定外の値が入った
といった場面で、
原因が追えないエラーに変わることがあります。
実務ではどちらを使うべきか？判断基準
RunSQLが向いているケース
RunSQLが必ずしも悪いわけではありません。
次のようなケースでは、RunSQLでも問題ないことがあります。
- 単発のデータ更新
- 操作する人が限定されている
- 影響範囲が小さい処理
- 将来的な拡張予定がない
いわば「道具として軽く使う」場面です。
DAO.Executeを選ぶべきケース
一方で、次のようなケースでは DAO.Executeを選ぶべきです。
- 一括更新・大量データ処理
- バッチ処理・自動処理
- 将来的に改修・拡張が想定される
- トラブル時に原因追跡が必要
特に、業務システムとして長く使われるAccessでは、
DAO.Executeを前提に設計しておく方が安全です。
実務でよくある失敗パターン
RunSQLのままシステムが肥大化する
最初は小さなシステムだったものが、
- 業務追加
- 担当者変更
- 処理件数増加
といった理由で成長し、
RunSQLだらけのブラックボックスになるケースは珍しくありません。
結果として、
- 誰も全体を把握できない
- 修正が怖くて触れない
- 改修コストが跳ね上がる
という状態に陥ります。
エラーが出ても原因が追えないSQL実装
On Error Resume Next と RunSQL の組み合わせは、
一見便利ですが非常に危険です。
- エラーが起きても気づかない
- データ不整合が静かに蓄積される
- 後から原因を追えない
「止まらない」ことと「正しく動いている」ことは別です。
将来のバージョンアップ・改修を見据えた考え方
Access延命と限界の境目
Accessは非常に優秀なツールですが、
使い方を間違えると限界が一気に表面化します。
SQL実装の考え方は、
そのまま以下に影響します。
- Accessの分割運用
- SQL Serverへの移行
- Webシステム化
SQL実装が移行難易度を左右する
DAO.Executeを前提に整理されたSQLは、
- 移行時に読みやすい
- 処理単位が明確
- 改修範囲を特定しやすい
一方、場当たり的に書かれたRunSQLは、
移行時に最もコストがかかる要因になりがちです。
まとめ｜Access VBAでSQLを実行するなら「今後」を考える
Access VBAでSQLを実行する方法として、
- RunSQLは「手軽な道具」
- DAO.Executeは「業務向けの道具」
と考えると分かりやすいでしょう。
重要なのは、
今動くかどうかではなく、今後どう使われるかです。
Accessは「とりあえず作れる」からこそ、
後から設計の差が大きく出ます。
システムキューブの「Accessの移行変換、mdb・adpのバージョンアップ」について
