【極限のVBA】Accessで「動的SQL」を扱うな。QueryDefsとパラメータを支配するアーキテクチャ
現場のコードを見ていると、未だに「文字列連結」でSQLを組み立てている悲劇的な実装に遭遇する。
`”SELECT FROM T_Sales WHERE SalesDate = #” & Me.txtDate & “#”`
これを見て「動いたからOK」と満足しているなら、今すぐそのキーボードから手を離してほしい。それは単なる実装ではなく、時限爆弾の製造だ。
今回は、Access VBAにおいて「動的SQL」という幻想を捨て、`QueryDefs`と`Parameters`コレクションを正しく使いこなし、堅牢でインジェクション耐性のあるシステムを構築するための「極限の知見」を伝授する。
—
1. なぜ「文字列連結」は死を招くのか
動的SQLの構築における最大の敵は、「型変換の曖昧さ」と「セキュリティリスク（SQLインジェクション）」だ。
特にAccessの場合、日付型や文字列型のクォーテーションの扱いを誤れば、実行時エラーや意図しないデータ抽出を招く。また、SQLが複雑化するほど、文字列連結のコードは視認性を失い、メンテナンス不可能な「スパゲッティ・コード」へと変貌する。
「SQLはコードの中に埋め込むな。オブジェクトとして管理せよ。」
これが、大規模システムを安定稼働させるための唯一の鉄則だ。
—
2. 賢者の選択：QueryDefsとパラメータの分離
Accessにおいて、クエリは単なる「文字列」ではない。`QueryDef`オブジェクトとしてデータベースに事前定義し、`Parameters`コレクションを通じて値を流し込むのが、Accessのアーキテクチャに則った唯一の正解だ。
この手法を採用するメリットは以下の3点に集約される。
1. 型の厳密な制御: パラメータ側で型を定義するため、クォーテーションや日付形式の悩みが消滅する。
2. コンパイルの恩恵: データベースエンジンが事前に実行計画を最適化できるため、パフォーマンスが向上する。
3. セキュリティ: SQL文とデータ値が明確に分離されるため、インジェクションの余地は物理的に存在しない。
—
3. 実装：プロフェッショナルなクエリ実行パターン
以下に、再利用性が高く、堅牢なプロダクションコードのテンプレートを示す。
‘ —————————————————————————
‘ 概要: パラメータクエリを実行し、動的なフィルタリングを実現する
‘ 備考: SQLは定数として保持し、実行時にパラメータを注入する
‘ —————————————————————————
Public Sub ExecuteSecureQuery(ByVal targetDate As Date, ByVal categoryID As Long)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
Set db = CurrentDb
‘ 事前にクエリを設計しておくか、一時クエリとして生成する
‘ ここでは「Q_Sales_Template」という名前の保存済みクエリを前提とする
Set qdf = db.QueryDefs(“Q_Sales_Template”)
‘ パラメータに値を安全に注入する
‘ これにより、SQLインジェクションは原理的に不可能となる
With qdf
.Parameters(“[prmDate]”) = targetDate
.Parameters(“[prmCategoryID]”) = categoryID
‘ Recordsetとして開く（必要に応じて処理）
Set rs = .OpenRecordset(dbOpenSnapshot)
End With
‘ — ここでデータ処理 —
If Not rs.EOF Then
Debug.Print “データ取得成功: ” & rs.RecordCount & “件”
End If
‘ クリーンアップ（メモリリークを許すな）
rs.Close
Set rs = Nothing
Set qdf = Nothing
Set db = Nothing
End Sub
クエリ側のSQL定義（Q_Sales_Template）
PARAMETERS [prmDate] DateTime, [prmCategoryID] Long;
SELECT FROM T_Sales
WHERE SalesDate = [prmDate] AND CategoryID = [prmCategoryID];
—
4. なぜこれが最強なのか：保守性の視点
このコードの美しさは、「SQLの変更がVBAの修正を必要としない」点にある。
- 仕様変更時: SQLの条件を変えたいなら、Accessのクエリデザイナ上でクエリを修正すればいい。VBAのコードを書き換える必要はない。
- デバッグ: 異常な動作があれば、クエリデザイナから直接パラメータを入力してテストできる。VBAのステップ実行を繰り返す必要はない。
5. チーフアーキテクトからの最終警告
Access開発において、多くのエンジニアが「動的SQL」を好む理由は、「その場で書けるから」という怠慢に過ぎない。しかし、その怠慢は将来の自分、あるいは後任のエンジニアを苦しめることになる。
- CurrentDbを都度呼び出さない: `Set db = CurrentDb` は一度だけにせよ。頻繁な呼び出しはオブジェクトのオーバーヘッドを招く。
- 変数のライフサイクル: `Set qdf = Nothing` を忘れるな。Accessのメモリ管理はルーズだが、複雑な処理になればなるほど、オブジェクトの解放忘れはアプリケーションを不安定にさせる。
「コードを短く書く」ことよりも、「誰が読んでも挙動が予測できるコード」を書くこと。それが真のエンジニアリングだ。今日から、文字列連結によるSQL構築は封印せよ。それこそが、君のツールを「おもちゃ」から「業務システム」へと昇華させる唯一の道だ。
