Access VBAの暗黒時代に終止符を。SQLを「コードの呪縛」から解き放つアーキテクチャ
現場のAccess開発者が陥る最大の罠、それは「VBAコードの中にSQLが埋没している」ことだ。
`strSQL = “SELECT FROM … WHERE …”` といった文字列連結が繰り返されるコードを見たとき、私は吐き気すら覚える。なぜなら、それは保守性を放棄し、修正のたびにバグを誘発する時限爆弾を埋め込んでいるのと同じだからだ。
今日は、クエリ定義（QueryDef）を外部ファイルから読み込み、VBAから切り離す「脱・ハードコーディング」の極意を伝授する。
—
なぜ「SQLの分離」が必須なのか
VBAモジュール内にSQLを直書きすることには、以下の致命的な欠陥がある。
1. 可読性の欠如: 長大なSQLが文字列として連結されると、構文の構造が視覚的に追えなくなる。
2. デバッグの困難さ: 実行時に生成されたSQLを確認するためには、`Debug.Print`を仕込んでイミディエイトウィンドウを睨むしかない。
3. 再利用性の放棄: 修正のたびにコンパイル（またはVBAの再編集）が必要となり、リリースサイクルが極端に遅くなる。
プロフェッショナルの仕事は「コードを書くこと」ではなく「変更に強い仕組みを作ること」だ。 SQLを外部テキストファイル（.sql）として切り出し、実行時に読み込む。これが正解だ。
—
堅牢なSQL外部読み込みエンジン（プロダクションコード）
以下のコードは、指定したテキストファイルからSQLを読み込み、既存の`QueryDef`を上書き更新するプロシージャである。エラーハンドリングとリソース解放のベストプラクティスを盛り込んでいる。
‘ 必要な参照設定: Microsoft DAO 3.6 Object Library 以上
Public Sub UpdateQueryFromExternalFile(ByVal queryName As String, ByVal filePath As String)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim fileNum As Integer
Dim sqlContent As String
On Error GoTo ErrorHandler
‘ 1. SQLファイルの読み込み
fileNum = FreeFile
Open filePath For Input As #fileNum
sqlContent = Input$(LOF(fileNum), fileNum)
Close #fileNum
Set db = CurrentDb
‘ 2. QueryDefの更新
‘ 存在しない場合は作成し、存在する場合はSQLを差し替える
If Not ExistsQuery(queryName) Then
Set qdf = db.CreateQueryDef(queryName, sqlContent)
Else
Set qdf = db.QueryDefs(queryName)
qdf.SQL = sqlContent
End If
Debug.Print “クエリ [” & queryName & “] を更新しました。”
CleanExit:
If Not qdf Is Nothing Then Set qdf = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “致命的なエラー: ” & Err.Description, vbCritical
Resume CleanExit
End Sub
‘ クエリが存在するかチェックするヘルパー関数
Private Function ExistsQuery(ByVal queryName As String) As Boolean
Dim qdf As Object
For Each qdf In CurrentDb.QueryDefs
If qdf.Name = queryName Then
ExistsQuery = True
Exit Function
End If
Next
End Function
—
運用上の極めて重要な注意点
この設計を導入するにあたり、以下の「現場の鉄則」を守らなければならない。
1. SQLファイルの文字コード
AccessのVBAは、基本的にはShift-JISかUTF-16を扱う。SQLファイルを保存する際は、文字化けを防ぐために「Shift-JIS（またはANSI）」で保存することを強く推奨する。UTF-8で保存すると、日本語のテーブル名やコメントが含まれる場合に動作が不安定になる可能性がある。
2. パラメーターの取り扱い
`QueryDef`の利点は、動的SQLを生成する際に`PARAMETERS`句を使えることだ。
SQLファイル内には、以下のように記述しておく。
PARAMETERS [prmID] Long;
SELECT FROM T_Order WHERE OrderID = [prmID];
こうすることで、VBA側からは `qdf.Parameters(“prmID”).Value = 123` といったセーフティな型指定が可能となり、SQLインジェクションのリスクを完全に排除できる。 文字列連結でSQLを組み立てるという素人じみた行為は、今すぐ卒業すべきだ。
3. 排他制御とパフォーマンス
`QueryDef`の更新は、データベースのスキーマ変更に近い挙動をする。マルチユーザー環境のフロントエンドでは、バックエンド側のクエリ定義を直接書き換えるのではなく、「ユーザー専用の一時的なQueryDefを作成するか、あるいはADOのCommandオブジェクトを使用する」という選択肢も常に頭に入れておいてほしい。
—
最後に：エンジニアとしての矜持
「動けばいい」というコードは、数ヶ月後の自分を殺す毒となる。
SQLを外部ファイル化し、ロジックとデータを分離する。この単純な一歩が、あなたの開発するAccessアプリケーションを、スパゲッティコードの迷宮から「メンテナンス可能な資産」へと変貌させる。
さあ、今すぐプロジェクト内のSQLをテキストファイルに書き出し、このアーキテクチャに置き換えなさい。それが、真の業務自動化エンジニアへの第一歩だ。
