Access VBAを掌握する：管理用クエリの「動的生成と隠蔽」による堅牢な権限管理
Accessというプラットフォームで、フロントエンドとバックエンドが密結合している環境において、もっとも頭を悩ませるのが「管理用機能のセキュリティ」だ。
一般的に、クエリをそのままナビゲーションウィンドウに置いておけば、リテラシーのあるユーザーであれば誰でも閲覧・修正が可能になる。これを防ぐためにフォームのアクセス権だけで制御するのは、もはや時代遅れであり、泥縄式だ。
真のエンジニアは、「必要な時に存在し、用が済めば消滅する」というオブジェクトのライフサイクルを制御することで、物理的に「実行権限」を担保する。今回は、QueryDefを戦術的に生成・破棄し、管理用クエリを闇に葬る実装の極意を伝授する。
—
1. なぜ「動的QueryDef」なのか
Accessの `QueryDef` は、保存された時点でデータベースのメタデータとして恒久的に記録される。これを「管理用」として残すことは、セキュリティ上の脆弱性を放置するに等しい。
我々が目指すべきは、以下のサイクルである。
1. 認可: 管理者権限をメモリ上で検証。
2. 生成: `CurrentDb.CreateQueryDef` で実行直前にクエリを定義。
3. 実行: `Execute` メソッドでトランザクションを完遂。
4. 掃討: `Delete` メソッドでオブジェクトを物理削除し、痕跡を消す。
この手法の最大の利点は、実行時以外の「クエリの存在」がゼロであることだ。ナビゲーションウィンドウをどれほど覗き込もうと、そこに管理用クエリは影も形も存在しない。
—
2. 実装の要諦：オブジェクトのライフサイクル管理
メモリリークを恐れるジュニアエンジニアは、`Set db = Nothing` を書くことに固執するが、真の制御は「スコープ」と「例外処理」にある。以下に、堅牢な管理用クエリ実行エンジンを示す。
‘ —————————————————————————
‘ 管理用クエリ実行プロシージャ
‘ メモリの断片化を避けるため、DAOオブジェクトを厳密に管理する
‘ —————————————————————————
Public Sub ExecuteAdminQuery(ByVal sqlString As String, ByVal queryName As String)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
‘ ユーザー権限チェック（独自実装の認証ロジックを想定）
If Not CurrentUser.IsAdministrator Then
MsgBox “権限がありません。”, vbCritical
Exit Sub
End If
Set db = CurrentDb
‘ 既存の同名クエリがあれば削除（万が一の残滓をクリーンアップ）
On Error Resume Next
db.QueryDefs.Delete queryName
On Error GoTo ErrorHandler
‘ 動的生成
Set qdf = db.CreateQueryDef(queryName, sqlString)
‘ クエリの実行
‘ ※dbFailOnErrorを指定し、失敗時は自動ロールバックさせるのが鉄則
db.Execute queryName, dbFailOnError
‘ 掃討（ここが重要：実行直後に削除して痕跡を消す）
db.QueryDefs.Delete queryName
Debug.Print “Admin Query Executed: ” & queryName
Cleanup:
Set qdf = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラー: ” & Err.Description, vbCritical
Resume Cleanup
End Sub
—
3. レガシー環境を生き抜く：パフォーマンスの最適化
上記のコードは一見シンプルだが、大規模なシステムにおいて `Delete` と `Create` を繰り返すと、Accessの内部的な「システムテーブル」が肥大化する可能性がある。
- コンパイルの効率化: `CreateQueryDef` を呼ぶ前に、SQL内のパラメーターを明示的に定義（`qdf.Parameters`）しておくことで、実行計画の再利用性が高まる。
- バックエンドの分離: 可能な限り、管理用クエリの実行はバックエンドDBに対して行う。フロントエンド側のシステムテーブルを汚さないのが、長期保守の秘訣だ。
- Windows APIによる監視: 特定の管理用機能にアクセスがあった際、`Kernel32.dll` の `GetUserName` を使い、誰が・いつ・どのクエリを生成しようとしたかを、ローカルの隠しログに記録する「監査ログ」の実装を推奨する。
—
4. チーフアーキテクトからの忠告
この手法は極めて強力だが、「銀の弾丸」ではない。
動的にクエリを生成するということは、「実行の瞬間にSQL文字列がメモリ上に展開される」ことを意味する。SQLインジェクション対策として、文字列連結によるクエリ生成は厳禁だ。必ず `Parameters` コレクションを使用し、値をクエリに渡すこと。
Access VBAはレガシーと言われるが、そのオブジェクトモデルは極めて洗練されている。データベースの内部構造を理解し、クエリの生死をエンジニアが掌中で制御する。これこそが、Access開発における「正義」である。
君たちのシステムが、ただ動くものではなく、意志を持って制御される堅牢なアーキテクチャであることを期待する。質問があればいつでも来い。現場の深淵で待っている。
