【テクニカル・上級編】ADOのCursorLocationプロパティの罠：ClientとServerの挙動を理解する – Access VBA解析バイブル

CursorLocationの深淵：ADOアーキテクチャにおけるメモリと通信の最適解

Access VBAを用いた大規模システム開発において、多くのエンジニアが「動けば良い」という思考停止に陥り、ADO（ActiveX Data Objects）の真の力を引き出せずにいる。その最たる例が、`CursorLocation` プロパティの選択だ。

`adUseClient` か `adUseServer` か。この二者択一は、単なるプロパティの設定ではない。それは、クライアント端末のメモリ空間をどのように占有するか、ネットワーク帯域をいかに消費するか、そしてデータベースとの排他制御をどう設計するかという、アーキテクチャの根幹に関わる意思決定である。

本稿では、レガシーなAccess環境からモダンなSQL Server連携までを俯瞰し、シニアエンジニアが知っておくべき「CursorLocationの真実」を抉り出す。

1. カーソルの所在：Client vs Server のメカニズム

まず、概念的な理解を正そう。カーソルとは、レコードセット内における「現在のポインタ」を指す。このポインタが「どこに存在するか」が、`CursorLocation` の本質である。

Server-Side Cursor (`adUseServer`)

カーソルはデータベースエンジン（SQL Server等）側に保持される。クライアントは、現在表示・処理に必要な最小限のデータのみを要求する。

• 利点: クライアント側のメモリ消費が極めて少ない。巨大なデータセットを扱う際でも、クライアントのメモリを圧迫しない。
• 欠点: レコードの移動（MoveNext等）のたびにネットワークを介した「ラウンドトリップ」が発生する。また、クライアント側でのソートやフィルタリングは不可能であり、すべてSQL文としてサーバーへ再送される必要がある。

Client-Side Cursor (`adUseClient`)

カーソルはクライアント（Accessプロセス）側のメモリ上に構築される。接続時に、条件に合致する全レコードがネットワークを流れてクライアントのメモリ空間に展開される。

• 利点: ネットワークのラウンドトリップが最小限になる（一度取得すれば、あとはメモリ内での高速移動が可能）。クライアント側での自由なソート、フィルタリング、および「切断されたレコードセット（Disconnected Recordset）」が可能。
• 欠点: 取得するデータ量に比例して、クライアントのメモリ消費が激増する。32bit版Accessを使用している場合、メモリ空間の限界（約2GB〜3GB）に達すると、即座に `Out of Memory` エラーを吐いてプロセスが死ぬ。

2. アーキテクトが直面する「メモリの罠」

シニアエンジニアが最も警戒すべきは、`adUseClient` によるメモリの断片化と枯渇である。

Access VBA（特に32bit環境）において、`adUseClient` を用いて数万件、数十万件のレコードを一度にロードするのは、極めてリスクの高い行為だ。たとえメモリに余裕があるように見えても、オブジェクトの解放が不適切であれば、メモリリークを引き起こし、システムの長時間稼働を不可能にする。

また、`adUseServer` を選択した際、意図しない「サーバーサイドのロック」が発生することも忘れてはならない。カーソルがサーバーに残ることで、トランザクションが長時間維持され、他のユーザーの更新を阻害する。これは、マルチユーザー環境におけるパフォーマンス低下の主犯である。

3. 実装戦略：Disconnected Recordset パターンの採用

私が推奨する極限の最適化手法は、「Disconnected Recordset（切断されたレコードセット）」の活用である。

これは、`adUseClient` を利用してデータをクライアント側に完全に引き込み、直ちにデータベースとの接続（Connection）を切断する手法だ。これにより、DBサーバーの負荷とロック時間を最小化しつつ、クライアント側で高速なデータ操作を実現できる。

以下に、その実装の規範を示す。

''' <summary>
''' 高速かつ安全にデータを取得し、接続を即座に解放するDisconnected Recordsetの実装例
''' </summary>
Public Function GetDisconnectedRecordset(ByVal strSQL As String) As ADODB.Recordset
    Dim cn As ADODB.Connection
    Dim rs As ADODB.Recordset
    
    On Error GoTo ErrorHandler

    ' 1. Connectionオブジェクトの生成
    Set cn = New ADODB.Connection
    ' ※接続文字列は環境に合わせて適切に管理すること
    cn.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Path\To\Your\Database.accdb;"

    ' 2. Recordsetの生成とCursorLocationの設定
    ' Client-sideを指定することで、メモリ上にデータを展開する準備を行う
    Set rs = New ADODB.Recordset
    rs.CursorLocation = adUseClient 

    ' 3. データの取得
    ' Openメソッドにより、指定したSQLの結果がクライアントメモリへロードされる
    rs.Open strSQL, cn, adOpenStatic, adLockOptimistic

    ' 4. 重要：接続の即時切断
    ' データのロードが完了した時点で、サーバーとの通信経路を閉じる
    ' これにより、サーバー側のリソース解放とロック回避を確実に行う
    cn.Close
    Set cn = Nothing

    ' 5. 結果の返却
    ' このrsはConnectionを持たない「切断された状態」である
    Set GetDisconnectedRecordset = rs
    Exit Function

ErrorHandler:
    ' オブジェクトのライフサイクルを厳格に管理し、エラー時もメモリを解放する
    If Not rs Is Nothing Then
        If rs.State = adStateOpen Then rs.Close
        Set rs = Nothing
    End If
    If Not cn Is Nothing Then
        If cn.State = adStateOpen Then cn.Close
        Set cn = Nothing
    End If
    Err.Raise Err.Number, "GetDisconnectedRecordset", Err.Description
End Function

''' <summary>
''' メインロジックでの利用例
''' </summary>
Public Sub ExecuteHighPerformanceTask()
    Dim rs As ADODB.Recordset
    Dim sql As String
    
    sql = "SELECT ID, CustomerName, OrderDate FROM Orders WHERE OrderDate >= #2023-01-01#"
    
    ' レコードセットの取得
    Set rs = GetDisconnectedRecordset(sql)
    
    If rs.EOF Then Exit Sub

    ' Client-side Cursorの恩恵：ネットワークを介さず、メモリ内で高速にループ
    Do Until rs.EOF
        Debug.Print rs!CustomerName.Value
        rs.MoveNext
    Loop

    ' --- 処理終了後の明示的な解放 ---
    ' VBAのガベージコレクションを待たず、エンジニアの意志でメモリを解放する
    rs.Close
    Set rs = Nothing
    
    Debug.Print "Process Completed Successfully."
End Sub

4. 結論：設計指針

アーキテクチャを決定する際、以下のマトリックスに従え。

エンジニアとしての矜持は、単にコードを書くことではなく、そのコードが実行されるマシンのメモリ、ネットワーク、そしてデータベースの負荷を、あたかも自分の手元にあるかのように制御することにある。

`CursorLocation` を制する者は、Access VBAにおけるパフォーマンスと安定性を制する。