【Access VBA極致】QueryDefの「フォーム直結」という甘美なる毒を絶つ
Access開発において、`QueryDef`オブジェクトは諸刃の剣だ。
SQLをコンパイル済み形式で保持し、実行プランを最適化するその性質は、パフォーマンスを追求するアーキテクトにとって必須の武器である。
しかし、多くの未熟な設計者が犯す致命的な過ちがある。それが、「SQLの中に直接 `Forms!FormName!ControlName` を埋め込む」という安直な実装だ。
今日は、なぜそれがシステムを崩壊させるのか、そして真のエンジニアがどのようにパラメータを制御すべきか、その極限の知見を共有する。
—
なぜ「フォーム直結」は罪深いのか
SQLの定義（`SQL`プロパティ）の中にフォームの参照を直接書き込むと、Accessのデータベースエンジンは、クエリが実行されるたびにそのコントロールの解決を試みる。
1. 疎結合性の破壊: クエリが特定のフォームの存在を前提とするようになり、再利用性がゼロになる。
2. デバッグの迷宮: 値がNullだったのか、あるいはコントロールが存在しないのか。SQLの実行エラーとVBAの例外が混ざり合い、スタックトレースが機能しなくなる。
3. 予期せぬ評価: `DoCmd.OpenQuery`を実行する際、Accessはバックグラウンドでフォームの状態を監視する。これがマルチスレッドに近い挙動を強いるため、メモリ競合や予期せぬロックの原因となる。
—
聖域の守り方：パラメータの明示的バインド
真のエンジニアは、SQLを「定義」と「データ」に完全に分離する。
`QueryDef`の `Parameters` コレクションを正しく使い、値の型を明示的にキャストする。これがメモリ管理とパフォーマンス向上の第一歩だ。
推奨される実装パターン
以下のコードは、フォーム上の値を安全に変数へ退避させ、型を保証した上でクエリに流し込むアーキテクチャである。
Public Sub ExecuteOptimizedQuery(ByVal strQueryName As String)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim prm As DAO.Parameter
Dim varValue As Variant
‘ 1. オブジェクトの安全な参照
Set db = CurrentDb
Set qdf = db.QueryDefs(strQueryName)
‘ 2. フォームの値を変数へ退避（ここでバリデーションを行う）
varValue = Forms(“frmSearch”)(“txtTargetDate”).Value
‘ 3. パラメータの明示的バインド
‘ SQL内の [pDate] と名前を一致させること
For Each prm In qdf.Parameters
Select Case prm.Name
Case “[pDate]”
‘ 型の安全性（Type Safety）を担保する
prm.Value = IIf(IsNull(varValue), Date, CDate(varValue))
End Select
Next prm
‘ 4. 実行とメモリ解放の徹底
‘ Recordsetを開く場合は必ず明示的にCloseし、Nothingを代入する
Dim rs As DAO.Recordset
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ — ビジネスロジック処理 —
‘ 5. 後処理（オブジェクトの寿命を制御する）
rs.Close
Set rs = Nothing
Set qdf = Nothing
Set db = Nothing
End Sub
—
アーキテクトの視点：メモリとライフサイクル
VBAのガーベジコレクションを過信してはいけない。特にレガシー環境や長時間稼働する端末では、`Set = Nothing` を怠ることは「緩やかな死」を意味する。
- `QueryDef`の使い回し: `QueryDef`を何度も `Set` しては放棄すると、`TempTables`やロックファイルが肥大化する。一度生成したオブジェクトは、可能な限り再利用する設計にすべきだ。
- 型変換のコスト: `Forms!Control` を直接 SQL に埋め込むと、毎回 Access がVariant型の暗黙変換を行う。これは微小だが、大量のループ処理内では無視できないオーバーヘッドとなる。変数経由で型を確定させて渡すことで、内部コンパイラは最適化されたパスを選択できる。
—
結論：技術は「規律」の上に成り立つ
Access VBAはレガシーと言われるが、その背後にある DAO（Data Access Objects）の設計思想は、現代の疎結合アーキテクチャにも通じる堅牢さを持っている。
「動けば良い」というコードは、メンテナンス時に自分自身を刺す刃となる。
「フォームに依存しないSQL」、「型を明示したパラメータ」、そして「オブジェクトの死を看取るメモリ管理」。
これら3つを徹底することこそが、Accessシステムを「管理されるべき負債」から「信頼できる資産」へと昇華させる唯一の道である。
さあ、コードを書き換えろ。あなたのシステムに平和と速度をもたらすために。
