Access VBAの深淵：QueryDefにおける「型不一致」を完全に封殺するアーキテクチャ
多くの開発者がAccess VBAで「型不一致エラー」に悶絶する。その原因は常に同じだ。DBエンジンのSQLパーサーと、VBAの緩やかな型システムとの間に横たわる「言語の境界線」を、甘い認識で越えようとするからだ。
特に`QueryDef`を用いた動的SQLの生成において、日付のフォーマットやNULLの扱いで躓くのは素人の所業。我々プロフェッショナルは、実行時に起きる「型不一致」をランタイムエラーとして放置せず、コンパイル時（あるいは関数内部）で完全に制御する。
今日は、VBAの変数型からSQLのデータ型を自動的に推論し、堅牢なパラメータークエリを生成するための「極限の型マッピング戦略」を伝授する。
—
1. なぜ「文字列結合」によるSQL生成は死を招くのか
`”WHERE ID = ” & varID` のようなコードを書いていないか？ それはSQLインジェクションの脆弱性を生むだけでなく、地域設定に依存した日付フォーマットの揺らぎを許容する「時限爆弾」だ。
`QueryDef`を使用する最大のメリットは、「SQLの構造」と「データ」を分離できることにある。パラメーター（`PARAMETERS`句）を明示的に定義し、型を固定する。これにより、Jet/ACEエンジンは実行計画を最適化し、型不一致のリスクを根絶できる。
2. 型マッピング・エンジン：実装の核心
VBAの`VarType`からSQLのデータ型を導き出し、`QueryDef`の`Parameters`コレクションへ安全に流し込むためのアダプター関数を実装する。
‘ @brief VBA型からDAOのDataTypeEnumへ変換し、パラメータをセットする
‘ @param qdf 対象のQueryDefオブジェクト
‘ @param paramName パラメータ名
‘ @param value 代入する値
Public Sub SetParameterSafe(ByRef qdf As DAO.QueryDef, ByVal paramName As String, ByVal value As Variant)
On Error GoTo ErrorHandler
‘ NULL値のハンドリングは最優先
If IsNull(value) Then
qdf.Parameters(paramName).Value = Null
Exit Sub
End If
‘ VBAの型に応じたDAO型へのマッピング
Select Case VarType(value)
Case vbInteger, vbLong: qdf.Parameters(paramName).Type = dbLong
Case vbDouble, vbSingle: qdf.Parameters(paramName).Type = dbDouble
Case vbDate: qdf.Parameters(paramName).Type = dbDate
Case vbString: qdf.Parameters(paramName).Type = dbText
Case vbBoolean: qdf.Parameters(paramName).Type = dbBoolean
Case Else: qdf.Parameters(paramName).Type = dbText
End Select
qdf.Parameters(paramName).Value = value
Exit Sub
ErrorHandler:
Err.Raise vbObjectError + 1000, “SetParameterSafe”, “パラメータ設定に失敗しました: ” & paramName
End Sub
3. オブジェクトライフサイクルの極意
シニアエンジニアであれば、DAOオブジェクトのメモリ解放が「推奨」ではなく「義務」であることを知っているはずだ。特にループ内で`QueryDef`を使い回す場合、オブジェクトの生成と破棄の管理が甘いと、メモリリークだけでなく、ロックファイルの肥大化やパフォーマンスの劣化を招く。
Public Sub ExecuteDynamicQuery(ByVal sql As String, ByVal params As Collection)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Set db = CurrentDb
‘ QueryDefを生成（一時的なクエリとして作成）
Set qdf = db.CreateQueryDef(“”, sql)
‘ パラメータの注入
Dim p As Variant
For Each p In params
‘ 事前に定義したマッパーで型を制御
SetParameterSafe qdf, p(0), p(1)
Next p
qdf.Execute dbFailOnError
‘ 【重要】明示的な破棄
qdf.Close
Set qdf = Nothing
Set db = Nothing
End Sub
4. レガシー環境とWindows APIの境界線
時として、Access単体では解決できない環境依存の問題（特定のOSバージョンにおけるJetエンジンの挙動など）に遭遇する。その際は、`kernel32.dll`を用いてシステム時刻を取得したり、メモリ管理を詳細に行う必要がある。
しかし、まずは「SQLの型管理」という基本を徹底すること。APIを呼び出す前に、DAOが提供する強力なパラメーターバインディング機能を使い切ること。これが、伝説的なシステムを維持し続けるための「守りの技術」だ。
結びに：真の自動化エンジニアへ
「動けばいい」というコードは、数年後の自分を殺す毒となる。
`QueryDef`の型定義を自動化し、メモリを厳密に管理する。この小さな規律の積み重ねこそが、数十年稼働する堅牢なAccessシステムの礎となる。
コードを書くとき、自問せよ。
「この変数に予期せぬ型が混入したとき、このコードは優雅にエラーを吐いて停止するか、それともシステム全体を汚染して沈黙するか？」
答えが後者なら、今すぐリファクタリングを始めるべきだ。健闘を祈る。
