応答不能の深淵を回避せよ：ADOにおけるタイムアウト制御とネットワーク断絶への防御アーキテクチャ
業務アプリケーションの設計において、最も醜悪な瞬間は「エラーが発生した時」ではない。「アプリケーションが応答を停止（Not Responding）し、ユーザーの操作を一切受け付けなくなる時」である。
特に、Access VBAをフロントエンドとし、SQL ServerやOracleといった外部DBをバックエンドに据えた分散環境において、ネットワークの瞬断や瞬時のパケットロスは「避けられない変数」だ。この変数を制御できず、OSレベルのブロッキングを許してしまう設計は、プロフェッショナルの仕事とは言えない。
本稿では、ADO（ActiveX Data Objects）における `ConnectionTimeout` と `CommandTimeout` の真の役割、そしてネットワークの不安定さに屈しないための、極限の防御実装について詳述する。
1. タイムアウトの二重構造：Connection vs Command
多くの開発者が陥る罠は、「タイムアウトを設定したはずなのに、アプリが固まる」という現象だ。これは、ADOにおけるタイムアウトが、通信のどのフェーズを制御しているのかを混同していることに起因する。
ConnectionTimeout：握手の拒絶
`ConnectionTimeout` プロパティは、「データベースサーバーへの接続確立（ハンドシェイク）」にかかる時間を制御する。
接続文字列（Connection String）が渡され、物理的なネットワーク層を経て、データベースエンジンが「接続を受け入れる準備ができているか」を確認するまでの時間だ。ネットワークが完全に切断されている、あるいはサーバーがダウンしている場合、ここが適切に設定されていないと、OSのTCP再送タイマーが働くまで、VBAの実行スレッドは無防備に待機し続ける。
CommandTimeout：沈黙への耐性
一方で `CommandTimeout` は、「接続確立後の、クエリ実行に対する応答待ち時間」を制御する。
接続は成功しているが、サーバー側で巨大な集計処理が走っている、あるいはネットワークの輻輳によりデータパケットが滞っている場合に、いつまで待ち続けるかを決定する。
「接続はできるが、データが返ってこない」状態を防ぐのが `CommandTimeout` であり、「そもそも接続すらできない」状態を早期に検知するのが `ConnectionTimeout` である。
2. 決定論的なオブジェクト管理とメモリ解放の責務
VBAはガベージコレクション（GC）によるメモリ管理を完全にコントロールできない。特にADOのようなCOMオブジェクトを扱う際、エラー発生時にオブジェクトのライフサイクルを放棄することは、メモリリークのみならず、接続プーリングの枯渇を招き、システム全体のパフォーマンスを漸次的に破壊していく。
極限の設計においては、`On Error GoTo` によるエラーハンドリングの中で、「何が起きても必ずオブジェクトを破棄する」という決定論的なクリーンアップ・パスを構築しなければならない。
3. 実装の真髄：堅牢な接続制御クラス
以下に、ネットワークの不安定さを前提とした、実戦的なADO接続制御のテンプレートを示す。ここでは、単なる接続コードではなく、タイムアウトの明示的設定と、Win32 APIを用いたネットワーク状態の事前確認、そして徹底したオブジェクト解放を組み込んでいる。
Option Compare Database
Option Explicit
' Windows API: ネットワークの接続状態を迅速に判定するための宣言
' 接続が完全に切断されている場合、無駄な接続試行を避けるために使用する
Private Declare PtrSafe Function InternetGetConnectedState Lib "wininet.dll" (ByRef lpdwFlags As Long, ByVal dwReserved As Long) As Long
''' <summary>
''' 堅牢なDB接続管理クラス（概念実装）
''' </summary>
Public Class SecureDBConnector
Private m_conn As ADODB.Connection
Private m_connString As String
' 設定値（環境に応じてチューニング）
Private Const CONN_TIMEOUT As Long = 5 ' 接続確立は5秒で諦める
Private Const CMD_TIMEOUT As Long = 30 ' クエリ実行は30秒で諦める
Public Sub Initialize(ByVal connectionString As String)
m_connString = connectionString
End Sub
''' <summary>
''' ネットワーク状態を確認し、安全に接続を確立する
''' </summary>
Public Function Connect() As Boolean
Dim dwFlags As Long
' 1. 事前チェック: OSレベルでネットワークが切断されていないか
If Not InternetGetConnectedState(dwFlags, 0) Then
Debug.Print "Critical: Network is disconnected. Aborting connection attempt."
Connect = False
Exit Function
End If
On Error GoTo ErrorHandler
' 2. オブジェクトの生成と初期設定
Set m_conn = New ADODB.Connection
' 重要: Openを呼ぶ前にConnectionTimeoutを設定しなければ意味がない
m_conn.ConnectionTimeout = CONN_TIMEOUT
' 3. 接続実行
' ここでネットワークが不安定だと、CONN_TIMEOUTに従って制御が戻る
m_conn.Open m_connString
' 4. 接続成功後のCommandTimeout設定
' このConnectionオブジェクトを使用するCommandに対し、デフォルトのタイムアウトを適用する
' (実際にはCommandオブジェクト生成時に設定するのが定石)
Connect = True
Exit Function
ErrorHandler:
' エラー内容のログ出力（本来はログファイルへ）
Debug.Print "Connection Error: " & Err.Number & " - " & Err.Description
' 5. 徹底したクリーンアップ
CleanUp
Connect = False
End Function
''' <summary>
''' Commandオブジェクトを用いた安全なクエリ実行
''' </summary>
Public Function ExecuteQuery(ByVal sql As String, ByRef rs As ADODB.Recordset) As Boolean
Dim cmd As ADODB.Command
On Error GoTo ErrorHandler
If m_conn Is Nothing Then Exit Function
Set cmd = New ADODB.Command
With cmd
.ActiveConnection = m_conn
.CommandText = sql
.CommandType = adCmdText
' クエリの実行タイムアウトを明示的に設定
.CommandTimeout = CMD_TIMEOUT
End With
Set rs = cmd.Execute
ExecuteQuery = True
' Commandオブジェクトはスコープを抜ける前に明示的に解放
Set cmd = Nothing
Exit Function
ErrorHandler:
Debug.Print "Execution Error: " & Err.Number & " - " & Err.Description
Set rs = Nothing
Set cmd = Nothing
ExecuteQuery = False
End Function
''' <summary>
''' オブジェクトの明示的解放（決定論的破棄）
''' </summary>
Private Sub CleanUp()
On Error Resume Next
If Not m_conn Is Nothing Then
If m_conn.State = adStateOpen Then m_conn.Close
Set m_conn = Nothing
End If
On Error GoTo 0
End Sub
Public Sub Disconnect()
CleanUp
End Sub
End Class4. アーキテクトの視点：なぜこの実装が「極限」なのか
このコードが一般的なリファレンスの実装と一線を画す理由は、以下の3点にある。
I. 防御的プログラミングの階層化
`InternetGetConnectedState` を用いた事前チェックは、無駄なリソース消費を防ぐための「第一の防壁」だ。ネットワークが死んでいる状態で `m_conn.Open` を試みることは、重い例外処理を発生させ、ユーザー体験を損なう行為である。
II. タイムアウトの局所化と明示化
`m_conn.ConnectionTimeout` を `Open` の直前に配置し、さらに `ADODB.Command` オブジェクトを介して `CommandTimeout` を個別に制御している。これにより、「接続は早々に諦め、重い処理には一定の猶予を与える」という、ビジネスロジックに基づいた柔軟な制御が可能になる。
III. 決定論的なリソース管理
`CleanUp` メソッドによる `Set obj = Nothing` の徹底。VBAにおいて、エラーハンドリング内でオブジェクトを放置することは、メモリの断片化と、将来的な「メモリ不足によるAccessの異常終了」の種を蒔くことと同義である。エラーが発生した瞬間、そのオブジェクトのライフサイクルを強制的に終了させる。これが、長時間稼働する基幹システムにおける鉄則である。
結論
Access VBAにおけるネットワーク通信の設計は、単に「データを取ってくること」だけを目的としてはならない。「通信が失敗した際に、いかに迅速に、かつ優雅に、システムを制御可能な状態に留めるか」。この一点に、シニアエンジニアとしての真価が問われる。
タイムアウトを制する者は、システムの可用性を制する。
