【入門編】SQL ServerのストアドプロシージャをADOで叩く際、パラメータ型を「VBAの型」に正しくマッピングする技術 – Access VBA解析バイブル

VBAとSQL Serverの「通訳」をマスターせよ：ADOパラメータで実現する、堅牢で高速なストアドプロシージャ呼び出し

こんにちは。開発の現場へようこそ。

Access VBAを使って業務アプリを作っていると、必ずと言っていいほど「データの置き場所」としてSQL Serverなどの外部データベース（RDBMS）を使う場面に直面します。

マクロの記録から一歩踏み出し、「もっと本格的なシステムを作りたい」と考えるようになったあなたにとって、「ADO（ActiveX Data Objects）を使って、SQL Serverのストアドプロシージャを叩く」というステップは、プロフェッショナルへの登竜門です。

しかし、ここで多くの初学者が、目に見えない「壁」にぶつかります。
「動くはずなのに、なぜか遅い」「たまに型エラーで止まる」「セキュリティが心配……」

これらはすべて、「VBAの型」と「SQL Serverの型」の間の『翻訳（マッピング）』が正しく行われていないことが原因です。今日は、この「翻訳」の極意を、伝説のアーキテクトの視点から丁寧に伝授しましょう。ここをクリアすれば、あなたの書くコードの信頼性は劇的に跳ね上がりますよ。

1. なぜ「文字列連結」ではいけないのか？

まず、初心者が陥りやすい「もっとも危険な書き方」を確認しておきましょう。

❌ 避けるべき書き方（文字列連結スタイル）

' 非常に危険で、パフォーマンスも悪い例
Dim strSQL As String
strSQL = "EXEC sp_UpdateEmployee '" & empID & "', '" & empName & "'"
conn.Execute strSQL

「これでも動くじゃないか」と思うかもしれません。確かに、小さなデータなら動きます。しかし、プロの現場ではこれは「禁忌」です。理由は3つあります。

1. SQLインジェクションの脆弱性: `empName` に `’ DROP TABLE Users; –` のような悪意ある文字列が入った瞬間、データベースが破壊されます。
2. 型変換のオーバーヘッド: VBAの値をすべて「文字列」としてSQL Serverに送り、SQL Server側で「これは数値だよね？」と解釈し直させるプロセスが発生します。これが積み重なると、システム全体のパフォーマンスを著しく低下させます。
3. インデックスの無効化: SQL Serverが「型が違うから、一旦全部変換してから検索しよう」と判断すると、せっかく貼ったインデックス（検索高速化の仕組み）が使われなくなり、処理が激重になります。

2. 正解は「ADO Commandオブジェクト」と「Parameter」

プロフェッショナルが使うのは、`ADODB.Command` オブジェクトです。
これは、VBAとSQL Serverの間に立つ「優秀な通訳」のようなものです。

「この値は `Integer` 型で、この値は `VarChar` 型ですよ」と、あらかじめ正確に伝えてあげることで、SQL Serverは迷うことなく、最速のルートで処理を実行できるのです。

✅ 正解の書き方（パラメータマッピング・スタイル）

以下に、実戦でそのまま使えるテンプレートを用意しました。

''' <summary>
''' ストアドプロシージャを実行するプロフェッショナルな実装例
''' </summary>
Public Sub ExecuteUpdateEmployee(ByVal empID As Long, ByVal empName As String)
    Dim cmd As ADODB.Command
    Dim conn As ADODB.Connection
    
    ' 接続の設定（実際は共通の接続関数などを使うのがベスト）
    Set conn = New ADODB.Connection
    conn.Open "Your_Connection_String_Here"
    
    ' Commandオブジェクトの生成
    Set cmd = New ADODB.Command
    
    With cmd
        .ActiveConnection = conn
        .CommandText = "sp_UpdateEmployee" ' 呼び出すストアド名
        .CommandType = adCmdStoredProc      ' ストアドであることを明示
        
        ' --- ここからが「型マッピング」の核心 ---
        
        ' パラメータ1: empID (SQL ServerのINT型に対応)
        ' CreateParameter(名前, 型, 方向, サイズ, 値)
        .Parameters.Append .CreateParameter("@empID", adInteger, adParamInput, , empID)
        
        ' パラメータ2: empName (SQL ServerのNVARCHAR型に対応)
        ' 文字列の場合は「サイズ」を明示するのが鉄則！
        .Parameters.Append .CreateParameter("@empName", adVarWChar, adParamInput, 50, empName)
        
        ' 実行！
        .Execute
    End With
    
    ' 後片付け
    cmd.Parameters.Refresh ' 必要に応じて
    conn.Close
    Set cmd = Nothing
    Set conn = Nothing
    
    Debug.Print "更新が正常に完了しました。"
End Sub

3. 【重要】型マッピングの対応表

「どのVBA型を、どのADO型に変換すればいいの？」という疑問に答える、魔法の対応表です。これを手元に置いておきましょう。

💡 ここがプロの視点：`adVarChar` vs `adVarWChar`

ここ、テストに出ますよ！
SQL Serverで日本語（Unicode）を扱うカラムが `NVARCHAR` の場合、ADOでは必ず `adVarWChar` を使ってください。`adVarChar` を使ってしまうと、文字化けや、型変換によるパフォーマンス低下を招きます。

4. 陥りやすいエラーと回避策

① 「パラメータの数が合いません」エラー

ストアドプロシージャ側で定義されている引数の数と、VBA側で `.Parameters.Append` した数が一致していない場合に発生します。
対策: ストアドの定義を必ず確認し、引数の順番通りに追加してください。

② 「サイズが足りません」エラー

`String` 型を渡す際、`CreateParameter` の第4引数（サイズ）を `0` や小さすぎる値にすると、データが切り捨てられたりエラーになったりします。
対策: DBの定義（例：`NVARCHAR(50)` なら `50`）を正確に指定してください。

③ トランザクションの管理（応用編）

複数のストアドを連続して叩く場合、途中でエラーが起きたら「全部なかったこと」にしたいですよね？その場合は、ADOのトランザクション機能を使います。

On Error GoTo ErrorHandler
conn.BeginTrans ' トランザクション開始

' --- ここで複数のコマンドを実行 ---
cmd.Execute 

conn.CommitTrans ' すべて成功したら確定
Exit Sub

ErrorHandler:
    conn.RollbackTrans ' 失敗したらすべて取り消し
    MsgBox "エラーが発生したため、処理をロールバックしました: " & Err.Description
End Sub

まとめ：型を制する者は、システムを制する

いかがでしたか？
「ただ値を渡すだけ」と思っていたパラメータ設定に、これほど深い意味があることに気づけたなら、あなたはもう初級者ではありません。

1. 文字列連結は卒業する（セキュリティと速度のため）。
2. `ADODB.Command` を使い、型を明示的に指定する。
3. `adVarWChar` など、Unicode対応を忘れない。

この3点を守るだけで、あなたの作るAccessアプリケーションは、まるでエンタープライズ級の堅牢なシステムのような振る舞いを見せるようになります。

一歩ずつ、着実に。コードの裏側にある「データの流れ」を感じながら、素晴らしい開発ライフを送ってくださいね。応援していますよ！