Access VBAの深淵：QueryDefを操り、フォームの描画を「極限」まで高速化する技術
Access開発において、多くのエンジニアが陥る罠がある。それは「フォームのレコードソースに直接長いSQL文字列を放り込む」あるいは「カレントデータベースのフィルタ機能を乱用する」という手法だ。
小規模なアプリならそれでいい。だが、データが10万件を超え、多人数で同時アクセスする環境下では、その設計は「時限爆弾」と化す。
今日は、QueryDefを動的に書き換え、フォームにバインドする手法を伝授する。これは単なるコードの書き方ではない。Accessのクエリ最適化エンジンを味方につけ、描画待ち時間を物理的に最小化する「アーキテクチャ」の話だ。
—
なぜ「動的SQLの直書き」は悪手なのか
フォームの `RecordSource` プロパティに直接SQL文字列を流し込むと、Accessは毎回そのSQLをパースし、実行計画を再計算する。特に複雑な結合（JOIN）を含む場合、このオーバーヘッドは無視できない。
QueryDefを介する利点：
1. 実行計画のキャッシュ: Accessのデータベースエンジンは、保存されたクエリの実行計画を最適化・保持する。
2. 保守性の分離: SQLがVBAのコード内から切り離されるため、SQLチューニングのみをクエリデザイナで行える。
3. トランザクションの安全性: フォーム側からは「名前」でクエリを参照するだけになるため、カプセル化が実現する。
—
【実戦コード】堅牢なQueryDef更新・バインド処理
以下のコードは、単にSQLを書き換えるだけでなく、「排他制御」と「エラーハンドリング」を考慮したプロダクション品質のモジュールだ。
‘ フォームのOpenイベント等で呼び出すことを想定した汎用関数
Public Function ApplyDynamicQuery(ByRef frm As Form, ByVal queryName As String, ByVal sqlContent As String) As Boolean
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
On Error GoTo ErrorHandler
Set db = CurrentDb
‘ 1. クエリ定義の存在確認と取得
Set qdf = db.QueryDefs(queryName)
‘ 2. SQLの更新（SQLが空の場合は例外を投げる設計）
If Trim(sqlContent) = “” Then Err.Raise 9999, , “SQL文が空です。”
qdf.SQL = sqlContent
‘ 3. フォームへのバインド
‘ SQLを直接渡すのではなく、クエリ名を参照させることで描画を最適化
frm.RecordSource = queryName
ApplyDynamicQuery = True
CleanExit:
Set qdf = Nothing
Set db = Nothing
Exit Function
ErrorHandler:
MsgBox “クエリ更新失敗: ” & Err.Description, vbCritical
ApplyDynamicQuery = False
Resume CleanExit
End Function
このコードの「設計思想」
- `ByRef frm As Form`: フォームそのものを渡すことで、どのフォームからも呼び出せる疎結合な設計にしている。
- `db.QueryDefs(queryName)`: 実行時に実体をキャッシュすることで、無駄なオブジェクト生成を抑えている。
- エラーハンドリング: 予期せぬSQL構文エラーが発生した場合でも、データベース接続（DAO）がゾンビ化しないよう `CleanExit` ラベルで確実にクリーンアップを行っている。
—
実務でハマる「落とし穴」への対策
1. 永続的な「書き込み」の弊害
QueryDefを更新すると、`.accdb` ファイルそのものが更新される。フロントエンドとバックエンドが分離されていない構成の場合、これが原因でファイルサイズが肥大化し、破損リスクが高まる。
対策: 必ず「フロントエンド・バックエンド構成」にし、QueryDefはフロントエンド側にのみ作成すること。
2. 同時実行性の考慮
複数のユーザーが同じクエリ名を書き換えると競合が発生する。
対策: ユーザーごとに一時的なクエリ名（例: `qTemp_User01`）を生成して処理するか、あるいはパラメータークエリを活用し、QueryDef自体の `SQL` プロパティを書き換えるのではなく、`Parameters` コレクションに値を渡す手法に切り替えるべきだ。
3. 「動的SQL」のセキュリティ
ユーザー入力をそのままSQLに連結するのは「SQLインジェクション」の温床だ。
対策: 可能な限り `Parameters` コレクションを使用し、値をクエリに渡す際は型を明示せよ。
—
結論：エンジニアの誇りとして
「とりあえず動く」コードを書くのは、Accessの初心者でもできる。しかし、「なぜそのSQLが遅いのか」「なぜこのオブジェクトのライフサイクルを管理しなければならないのか」を理解して書くコードは、数年後のメンテナンスコストを劇的に下げる。
QueryDefを動的に扱うこの設計は、Accessというプラットフォームの限界性能を引き出すための「標準装備」だ。今日から、君のプロジェクトのコードから「直書きSQL」を追放し、より洗練された設計へと昇華させてほしい。
何か不明点があれば、またいつでも聞いてくれ。極限の現場で培った知見を、惜しみなく提供する。
