こんにちは！開発現場を渡り歩くうちに、いつの間にかAccessのダークサイド…いや、奥深い世界にハマり込んでしまった君。今日はすごくいいテーマを持ってきたよ。
「Accessって、データが増えると途端に動きが重くなるよね……」
「VBAで頑張ってループ処理を書いてたら、コーヒーを飲み終わっても終わらないよ……」
そんな絶望を味わったことはないかい？
もし君が今、バックエンドにSQL Serverを使っているなら、Accessの限界を軽々と突破する秘密兵器がある。それが「パススルー・クエリによるストアドプロシージャの呼び出し」だ。
今回は、Access VBAを使ってSQL Serverのエンジンをフル回転させ、処理速度を何倍にも跳ね上げる実践的アプローチを、優しく、そして骨太に解説しよう。ここをクリアすれば、君はもう「ただのAccess使い」じゃない。立派なデータアーキテクトの仲間入りさ。
—
1. なぜ「パススルー・クエリ」なのか？（基本のキ）
通常、Accessでクエリを作ると、Accessのエンジン（ACE/Jet）が頑張ってデータをローカル（君のパソコン）に引っ張ってきてから計算やフィルタリングを行う。これを「クライアントサイド処理」と言う。数万件ならまだしも、数百万件のデータがあったらネットワークはパンクし、Accessはフリーズする。
一方、パススルー・クエリとは、文字通り「SQLをAccessで翻訳せず、そのままSQL Serverへ丸投げする」仕組みだ。
[Access (VBA)]
↓ 「おい、このSQLをそのままSQL Serverで実行してくれ！」（パススルー）
[SQL Server]
↓ 猛烈なパワーで計算・処理
↓ 結果だけをサクッと返す
[Access] ➔ 爆速で完了！
さらに、SQL Server側にあらかじめ用意されたプログラムである「ストアドプロシージャ」をこのパススルー経由で叩くことで、ネットワークの負荷を最小限に抑えつつ、サーバーの最強の計算リソースを極限まで引き出すことができるんだ。
—
2. 現場で使える！動的QueryDef生成の実装パターン
「でも、実行するたびにパラメータ（条件）が変わるんだけど？」
その通り。実務では、画面に入力された日付やIDなどの条件に合わせて、SQLやストアドの呼び出し文を動的に組み立てる必要がある。
ここで登場するのが、Access VBAの`QueryDef`オブジェクトだ。
以下のコードを見てほしい。これは、画面のフォームから受け取ったパラメータを組み込んで、一時的なパススルー・クエリを動的に生成し、SQL Serverのストアドプロシージャを実行する実践的なサンプルコードだ。
Public Sub ExecuteServerStoredProcedure()
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim strQueryName As String
Dim strConnect As String
Dim strSQL As String
On Error GoTo ErrorHandler
Set db = CurrentDb
strQueryName = “tmp_PassThrough” ‘ 動的に生成・削除するクエリ名
‘ 1. 接続文字列の定義（ODBC経由でSQL Serverに接続）
‘ ※環境に合わせてサーバー名やDB名を変更してください
strConnect = “ODBC;DRIVER={SQL Server Native Client 11.0};” & _
“SERVER=192.168.1.50;DATABASE=SalesDB;” & _
“Trusted_Connection=Yes;”
‘ 2. 既存の同名クエリがあれば削除（クリーンアップ）
For Each qdf In db.QueryDefs
If qdf.Name = strQueryName Then
db.QueryDefs.Delete strQueryName
Exit For
End If
Next qdf
‘ 3. 新規にQueryDefオブジェクトを作成
Set qdf = db.CreateQueryDef(strQueryName)
‘ 4. クエリのプロパティを設定（これがパススルーの命！）
qdf.Connect = strConnect
qdf.ReturnsRecords = False ‘ 今回は結果を返さない（更新系ストアド）のでFalse
‘ 5. ストアドプロシージャを呼び出すSQLを動的に構築
‘ フォームから値を取得する想定（例: Me.txtStartDate, Me.txtEmployeeID）
strSQL = “EXEC sp_UpdateMonthlySales ” & _
“@TargetYM = ‘202310’, ” & _
“@EmpID = ” & Me.txtEmployeeID
qdf.SQL = strSQL
‘ 6. 実行！
qdf.Execute dbFailOnError
MsgBox “ストアドプロシージャの実行が正常に完了しました。”, vbInformation, “成功”
CleanUp:
‘ 7. オブジェクトの解放（メモリリークを防ぐプロの作法）
If Not qdf Is Nothing Then
qdf.Close
Set qdf = Nothing
End If
Set db = Nothing
Exit Sub
ErrorHandler:
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical, “異常終了”
Resume CleanUp
End Sub
コードの重要なポイント解説
- `qdf.Connect` の設定: これを指定することで、このQueryDefはAccessのクエリではなく「外部SQL Serverへの直通回線」に変貌する。
- `ReturnsRecords = False`: データを取得（SELECT）する場合は `True`（レコードセットが返る）、データを更新・追加・削除（INSERT/UPDATE/DELETEやストアドでのバッチ処理）する場合は `False` に設定する。ここを間違えるとエラーになるので注意が必要だ。
- オブジェクトの解放: VBAでは、`Set qdf = Nothing` のように使い終わったオブジェクトを確実に解放することが、Accessを安定稼働させるための絶対の鉄則だよ。
—
3. 初学者が必ずハマる「3大トラップ」と回避策
この手法を実装するとき、多くのエンジニアが同じ壁にぶつかる。先輩からのアドバイスとして、あらかじめ頭に入れておこう。
トラップ1：SQLインジェクションと型の不一致
上のコードのように、VBAの文字列連結で `& Me.txtEmployeeID` のように書くと、もし入力値が文字列だった場合にシングルクォート（`’`）を付け忘れてSQLエラーになったり、悪意ある入力を許してしまう危険（SQLインジェクション）がある。
- 対策: 文字列パラメータを渡すときは、必ずシングルクォートで囲むこと。`”‘” & Me.txtInput & “‘”`
- 更なる高みを目指すなら、パススルーではなくAccessの通常のパラメータクエリ（DAOのParametersコレクション）を使う手もあるが、ストアドを叩くパススルーの場合はエスケープ処理を丁寧に行うのが現実的だ。
トラップ2：ODBCの接続タイムアウト
重いストアドを呼び出した際、Access側がデフォルトのタイムアウト時間（通常は60秒）を超えてしまい、途中で切断されてしまうことがある。
- 対策: クエリを実行する前に、`db.QueryTimeout = 300` のようにタイムアウト時間を長めに設定しておこう。（※ただし、SQL側のチューニングが本来の根本解決であることを忘れないように！）
トラップ3：一時クエリのゴミ屋敷化
コード内で `tmp_PassThrough` のような一時クエリを作る際、エラーハンドリングの不備で削除処理がスキップされると、Accessの裏側にゴミクエリが溜まり続け、ファイルサイズが肥大化・破損の原因になる。
- 対策: 今回のサンプルコードのように、必ずエラー時でも通る `CleanUp` ラベルの中でクエリのクローズと変数解放を行うこと。
—
まとめ：ここをクリアすれば、Access VBAは怖くない！
お疲れ様！今回は「Access VBAからパススルー・クエリを使ってSQL Serverのストアドプロシージャを動的に叩く」という、実務に直結するハイレベルな手法を解説した。
- 重い処理はAccessにやらせず、SQL Serverにパススルーで丸投げする。
- 状況に応じたSQLをQueryDefで動的に組み立てる。
- メモリとコネクションのライフサイクルを意識して、綺麗に後片付けをする。
この3つさえ押さえておけば、君が作るAccessシステムは、もはや「おもちゃのデータベース」なんかじゃない。基幹システムをも支える、堅牢で爆速なフロントエンドに生まれ変わるはずだ。
分からないことがあれば、いつでも何度でもこのページに戻ってきてほしい。
君のエンジニアとしての飛躍を、心から応援しているよ！さあ、エディターを開いてコードを書いてみよう！
