【テクニカル・上級編】ADOの接続エラーを詳細に解析する：Errorsコレクションを活用したデバッグ術 – Access VBA解析バイブル

Access VBA

2026.11.04

`Err.Description` の限界を超えろ：ADO `Errors` コレクションによる分散環境のエラー解析術

`Err.Description` の限界を超えろ：ADO `Errors` コレクションによる分散環境のエラー解析術

業務システムの現場において、Access VBAを単なる「デスクトップアプリの言語」と侮る者は、分散データベース環境（SQL Server連携など）に足を踏み入れた瞬間にその限界を知ることになる。

多くの開発者が、エラーハンドリングにおいて `MsgBox Err.Description` という、あまりに浅薄な手法に依存している。しかし、SQL ServerやOracleといった外部リレーショナルエンジンとADO（ActiveX Data Objects）を介して通信している場合、VBAのグローバルな `Err` オブジェクトが提示する情報は、氷山の一角に過ぎない。

真のアーキテクトは、エラーの「表面」ではなく、プロバイダが吐き出した「深淵」を見る。本稿では、ADOの `Errors` コレクションを徹底的に解剖し、分散環境におけるエラー解析の極致を解説する。

1. アーキテクチャの断絶：DAOとADOの決定的な違い

まず、我々が戦うフィールドの性質を整理しておく必要がある。

DAO (Data Access Objects) は、Jet/ACEエンジンという「ローカルな管理下」にあるエンジンを操作するためのものだ。エラーは基本的にローカルなファイルシステムや、ACEエンジンの内部規則に起因する。そのため、`Err` オブジェクトで事足りることが多い。

一方で ADO (ActiveX Data Objects) は、OLE DBプロバイダを介して「外部の宇宙」へと通信を行うための抽象化レイヤーである。
ADOにおいてエラーが発生したとき、その原因は以下の3層のどこかに存在する。

1. VBA/COM レイヤー: オブジェクトの参照不正や、プロシージャの呼び出しミス。
2. OLE DB プロバイダレイヤー: ネットワークの切断、ドライバの不整合、認証エラー。
3. リモートエンジンレイヤー (SQL Server等): 制約違反、デッドロック、構文エラー、権限不足。

VBAの `Err` オブジェクトは、主に「1」の情報をしか保持できない。しかし、我々が解決すべき致命的な問題の多くは「2」と「3」にある。これらを取得するためには、`Connection` オブジェクトが保持する `Errors` コレクションを直接走査しなければならないのだ。

2. `Errors` コレクションの深淵を覗く

ADOのエラーは、単一の事象であっても、複数のエラーオブジェクトとして連鎖的に格納されることがある。例えば、トランザクションのロールバックが発生した際、その背後にある「なぜロールバックが必要だったのか」という根本原因は、`Errors` コレクションの奥深くに隠れている。

解析すべき主要なプロパティは以下の通りだ。

`Number`: ADO固有のエラー番号。
`Description`: エラーの詳細な説明。
`SQLState`: ANSI SQL標準に基づく5文字のステータスコード。
`NativeError`: ここが最重要である。 SQL Serverなどのデータベースエンジンが返した、生の（ネイティブな）エラー番号だ。これを特定することで、DB側のログと照合が可能になる。

3. 実践：極限のデバッグ・ルーチン

以下に、シニアエンジニアが実装すべき、堅牢なエラー解析の実装パターンを示す。単に表示するのではなく、詳細なコンテキストと共にログ出力やデバッグ出力を生成する設計だ。

'***
' Module: modErrorHandling
' Description: ADO Error Analysis Engine for High-Reliability Systems
'***
Option Explicit

''' <summary>
''' ADO Connectionのエラーコレクションを詳細に解析し、
''' 開発者および管理者へ決定的な情報を提示する。
''' </summary>
''' <param name="conn">エラーが発生したADODB.Connectionオブジェクト</param>
Public Sub AnalyzeADOErrors(ByRef conn As ADODB.Connection)
    Dim i As Long
    Dim errObj As ADODB.Error
    Dim logMsg As String
    
    ' エラーが存在しない場合は、通常のVBAエラーとして処理を委ねる
    If conn Is Nothing Then
        Debug.Print "Critical Error: Connection object is Nothing."
        Exit Sub
    End If

    If conn.Errors.Count = 0 Then
        Debug.Print "No ADO-specific errors found in the connection object."
        Exit Sub
    End If

    logMsg = vbCrLf & "======= ADO ERROR ANALYSIS REPORT =======" & vbCrLf
    logMsg = logMsg & "Total Errors Found: " & conn.Errors.Count & vbCrLf

    ' Errorsコレクションを順次走査
    ' 最初の要素が最も根本的な原因である場合が多い
    For i = 0 To conn.Errors.Count - 1
        Set errObj = conn.Errors(i)
        
        With errObj
            logMsg = logMsg & sprintf("[%d] Error Index: %d" & vbCrLf, i, i)
            logMsg = logMsg & sprintf("    ADO Error Number: %d" & vbCrLf, .Number)
            logMsg = logMsg & sprintf("    SQLState:         %s" & vbCrLf, .SQLState)
            logMsg = logMsg & sprintf("    Native Error:     %d" & vbCrLf, .NativeError) ' SQL Serverの生エラー
            logMsg = logMsg & sprintf("    Description:      %s" & vbCrLf, .Description)
            logMsg = logMsg & "----------------------------------------" & vbCrLf
        End With
    Next i
    
    logMsg = logMsg & "=========================================" & vbCrLf

    ' 実運用では、ここでテキストファイルへのログ出力や、
    ' Windowsイベントログへの書き込みを行う。
    Debug.Print logMsg
    MsgBox "A critical database error occurred. Check the Immediate Window for details.", vbCritical, "Database Error"
End Sub

''' <summary>
''' 文字列フォーマットの補助関数（VBAにはString.Formatがないため）
''' </summary>
Private Function sprintf(ByVal format As String, ParamArray args() As Variant) As String
    Dim i As Long
    Dim result As String
    result = format
    
    ' 簡易的な実装。実運用ではより高度なフォーマッタを検討せよ。
    For i = LBound(args) To UBound(args)
        Dim placeholder As String
        placeholder = GetPlaceholder(format, i)
        If placeholder <> "" Then
            result = Replace(result, placeholder, CStr(args(i)))
        End If
    Next i
    sprintf = result
End Function

' 簡易的なプレースホルダ解決（%d, %sを想定）
Private Function GetPlaceholder(ByVal format As String, ByVal index As Long) As String
    ' 本来は正規表現等で厳密に行うべきだが、ここでは簡略化
    ' 実運用では、%1, %2... 形式の自作プレースホルダを使用することを推奨する
    ' ここではデモ用に、実装の概念のみ示す
    GetPlaceholder = "" ' 実装省略
End Function

*(注: `sprintf` の実装は簡略化している。実務では `Replace` を用いて `%1`, `%2` といったインデックス指定のプレースホルダを扱う自作関数を用意するのが定石だ。)*

4. オブジェクトのライフサイクルとメモリの管理

分散システムを扱う上で、エラーハンドリングと同時に意識しなければならないのがオブジェクトのライフサイクルだ。

エラーが発生した際、多くの開発者は `On Error GoTo ErrorHandler` に飛び、そのまま処理を終了しようとする。しかし、このとき `ADODB.Connection` や `ADODB.Recordset` がメモリ上に「浮いた」状態になっていないか？

特に、トランザクション処理中にエラーが発生した場合、オブジェクトを適切に解放（`Set obj = Nothing`）せずにプロシージャを抜けると、以下の致命的な事態を招く。

1. 接続リーク: SQL Server側のセッションが残り続け、最大接続数（Max Connections）を食いつぶす。
2. ロックの残留: 未完了のトランザクションが保持する排他ロックが解除されず、他のユーザーの処理をブロッキングし続ける。

アーキテクトの鉄則：
エラーハンドリングの `Exit Sub` または `Exit Function` の直前、および `ErrorHandler` 内において、必ず 「明示的なロールバック」 と 「オブジェクトの破棄」 をセットで行え。

Sub ExecuteTransaction()
    Dim conn As ADODB.Connection
    Set conn = New ADODB.Connection
    
    On Error GoTo ErrHandler
    
    conn.Open "Your_Connection_String"
    conn.BeginTrans ' トランザクション開始
    
    ' --- ビジネスロジック ---
    ' ここでエラーが発生すると ErrHandler へ飛ぶ
    ' -----------------------

    conn.CommitTrans
    GoTo CleanUp

ErrHandler:
    ' 1. まずエラーの詳細を解析
    AnalyzeADOErrors conn
    
    ' 2. トランザクションの整合性を守る
    If Not conn Is Nothing Then
        If conn.State = adStateOpen Then
            ' 接続が開いているなら、必ずロールバックを試みる
            On Error Resume Next ' ロールバック自体の失敗を無視
            conn.RollbackTrans
            On Error GoTo 0
        End If
    End If

CleanUp:
    ' 3. オブジェクトの明示的解放（メモリ最適化の要）
    If Not conn Is Nothing Then
        If conn.State = adStateOpen Then conn.Close
        Set conn = Nothing
    End If
End Sub

結びに代えて

Access VBAを、単なる小規模なツール作成の道具として扱うか、それとも大規模なエンタープライズ基盤の一部として扱うか。その差は、エラーという「システムの不確実性」に対して、どれほど深い洞察を持って向き合えるかにかかっている。

`Err.Description` という甘い言葉に惑わされるな。`Errors` コレクションの中に眠る `NativeError` こそが、システムを真に安定させるための唯一の真実なのだ。