Access VBAを掌握せよ：DAO.QueryDefの「型不一致」を封殺する堅牢なパラメータ制御術
Access開発の現場で、初心者が最も速く「絶望」を味わう瞬間がある。それは、動的に生成したSQLを`DAO.QueryDef`に流し込み、実行した瞬間に突きつけられる「データ型が一致しません（3421）」という冷徹なエラーだ。
なぜこのエラーが起きるのか？
AccessのDBエンジン（ACE）は、クエリの実行時にパラメータの型を厳密に解釈しようとする。文字列を期待する箇所にNullを突っ込んだり、日付型を曖昧な文字列として渡したりすれば、エンジンは即座に停止する。
今日は、小手先の回避術ではなく、「データベースの整合性を守るためのアーキテクチャ」としてのパラメータ制御を伝授する。
—
なぜ「SQL文字列の連結」で設計してはいけないのか
多くの開発者は、SQL文字列の中に変数値を直接埋め込む手法をとる。
‘ 悪手：SQLインジェクションのリスクと型変換の地獄が待っている
strSQL = “SELECT FROM T_Orders WHERE OrderDate = #” & myDate & “#”
これの何が問題か？
1. ロケール依存の恐怖: 日付フォーマットがOS設定（MM/DD/YYかDD/MM/YYか）に依存し、環境が変わった瞬間に爆発する。
2. 特殊文字の罠: 顧客名に「’（シングルクォート）」が含まれていただけで、SQL構文は崩壊する。
3. パフォーマンスの欠如: 実行のたびにSQLが再コンパイルされ、プランキャッシュが効かない。
これらを解決する唯一無二の解が、`DAO.QueryDef`のパラメータ明示的指定である。
—
堅牢なパラメータ設定のための「型変換エンジンの構築」
プロフェッショナルは、パラメータを渡す際に「型を疑う」ことから始める。以下は、私が長年の開発で洗練させてきた、DAO.QueryDef用の型変換ライブラリだ。
実践的なプロダクションコード
この関数は、VBAのVariant型を、AccessのDBエンジンが確実に解釈できるDAOの型へ強制的に変換する。
Option Compare Database
Option Explicit
‘ DAO.QueryDefのパラメータを安全に設定するラッパー関数
Public Sub SetParameterSafe(ByRef qdf As DAO.QueryDef, ByVal paramName As String, ByVal val As Variant)
Dim prm As DAO.Parameter
‘ 存在しないパラメータを指定した場合の即時検知
On Error Resume Next
Set prm = qdf.Parameters(paramName)
If Err.Number <> 0 Then
Err.Raise vbObjectError + 1000, “SetParameterSafe”, “パラメータ ‘” & paramName & “‘ が定義されていません。”
End If
On Error GoTo 0
‘ NULL値の明示的ハンドリング
If IsNull(val) Then
prm.Value = Null
Else
‘ 型に応じたキャスト
Select Case VarType(val)
Case vbDate
prm.Value = CDate(val)
Case vbString
prm.Value = CStr(val)
Case vbDouble, vbDecimal, vbLong, vbInteger
prm.Value = CDec(val)
Case Else
prm.Value = val
End Select
End If
End Sub
—
現場でどう実装するか：設計思想の適用
この関数を使った、保守性の高いクエリ実行パターンがこれだ。
Public Sub ExecuteReportQuery()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Set db = CurrentDb
‘ あらかじめ定義したクエリ（PARAM… を含むもの）を呼び出す
Set qdf = db.QueryDefs(“qry_TargetReport”)
‘ 型を意識することなく、安全に値を注入する
SetParameterSafe qdf, “[prm_StartDate]”, Me.txtStartDate.Value
SetParameterSafe qdf, “[prm_CategoryID]”, Me.cmbCategory.Value
‘ 実行
qdf.Execute dbFailOnError
Set qdf = Nothing
Set db = Nothing
End Sub
なぜこの設計が最強なのか
1. カプセル化: 型変換のロジックが`SetParameterSafe`に集約されているため、将来的なデータ型の変更や追加があっても、修正箇所は一箇所で済む。
2. 保守性: `DAO.QueryDef`を使うことで、クエリの設計はGUI（Accessのクエリデザイナ）で行い、VBAは「データの受け渡し」に専念できる。役割分担が明確だ。
3. 堅牢性: `dbFailOnError`を使用することで、実行時に発生したエラーをVBA側で捕捉可能にする。データが中途半端に更新される事故を防ぐ。
—
チーフアーキテクトからの助言
Access VBAは、歴史が長い分、古い書き方がインターネットに氾濫している。「動けばいい」というコードは、半年後の自分を苦しめる負債になるだけだ。
パラメータクエリを制することは、Accessというデータベース環境そのものを制することと同義だ。DAOオブジェクトのライフサイクルを理解し、型を制御し、SQLを「文字列」ではなく「構造体」として扱う。この感覚を身につけた時、あなたの作るツールは、単なるスクリプトから、堅牢な業務システムへと進化する。
次回の開発からは、SQLの中に無理やり変数をねじ込むのはやめよう。それは、貴方のエンジニアとしての品位を損なう行為だ。まずは、この`SetParameterSafe`をプロジェクトに組み込むことから始めてみてほしい。
