ADOのCursorLocationプロパティの罠：ClientとServerの挙動を理解する
業務自動化の現場で、Access VBAを用いた大規模なデータ連携システムを設計していると、必ずと言っていいほど直面する壁がある。
「レコードセットを開いた瞬間にメモリが跳ね上がる」
「データは取得できているのに、`Update`メソッドを呼ぶと『オブジェクトが更新できません』と突き放される」
これらの問題の多くは、ADO（ActiveX Data Objects）の基本中の基本、`CursorLocation`プロパティの理解不足に起因している。多くの開発者は、なんとなく `adUseClient` を指定して「とりあえず動く」状態を作る。しかし、それはプロフェッショナルの設計ではない。
今回は、アーキテクトの視点から、`CursorLocation` がオブジェクトのライフサイクル、メモリ消費、そして更新可否にどのような決定的な差をもたらすのかを解剖する。
1. 核心：CursorLocationが決定する「データの居場所」
`CursorLocation` プロパティとは、一言で言えば「レコードセットのカーソル（現在地）と、そのデータ実体をどこに保持するか」を指定するものである。
Server-Side Cursor (`adUseServer`)
カーソルとデータセットの管理を、データベースエンジン（サーバー側）で行う。クライアント（Access側）は、サーバーに対して「次のレコードをくれ」「このレコードを更新してくれ」と命令を投げるだけの「窓口」となる。
- メリット: クライアント側のメモリ消費が極めて少ない。巨大なテーブルから数行だけを抽出する場合に最適。
- デメリット: ネットワークの往復（Round-trip）が発生するため、レコード移動のたびにオーバーヘッドが生じる。また、Access特有の挙動として、更新が制限されたり、複雑なフィルタリングができなかったりする制約が多い。
Client-Side Cursor (`adUseClient`)
レコードセット全体を、クライアント（Accessのメモリ空間）に一度丸ごとダウンロードする。
- メリット: 全データが手元にあるため、`Filter` や `Sort` が瞬時に動作し、レコードの前後移動も高速。何より、高度な更新操作やバッチ更新が極めて安定する。
- デメリット: 数十万件規模のデータを不用意に取得すると、Accessのメモリ空間を食いつぶし、即座に「メモリ不足」でクラッシュする。
2. なぜ「更新できない」というバグが起きるのか
現場で最も多いトラブルが、`adUseServer` を使用している際に発生する「更新不可」問題だ。
Server-side カーソルは、データベースエンジンが「今、どの行を見ているか」を厳格に管理する。しかし、複雑なJOINを含むクエリや、特定のプロバイダを経由した接続では、サーバー側が「この操作は更新可能である」という確証を持てず、ReadOnlyなレコードセットとして返してしまうことが多々ある。
一方で、`adUseClient` を選択すれば、データは一度クライアントのメモリに「スナップショット」として展開される。この「手元にあるデータ」に対して操作を行うため、プロバイダの制約を受けにくく、堅牢な更新処理が可能になるのだ。
アーキテクトの判断基準:
> 「データの読み取り専用の集計処理」なら Server。
> 「ユーザー入力に基づいたデータの追加・修正・削除」を伴うなら Client。
これが鉄則だ。
3. 実践：堅牢なプロダクションコード・パターン
単に `adUseClient` を書くだけでは不十分だ。トランザクション処理、エラーハンドリング、そしてオブジェクトの確実な解放。これらが組み合わさって初めて「業務に耐えうるコード」となる。
以下に、私が設計の現場でテンプレートとして使用している、高信頼性なADO操作のコードを示す。
Option Explicit
''' <summary>
''' クライアントサイドカーソルを用いた、堅牢なレコード更新プロシージャ
''' </summary>
Public Sub ExecuteSecureUpdate()
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strConn As String
Dim targetID As Long
' 設定値
targetID = 101
strConn = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\YourPath\YourDatabase.accdb;"
' オブジェクトの初期化
Set cn = New ADODB.Connection
Set rs = New ADODB.Recordset
On Error GoTo ErrorHandler
' 1. 接続の確立
cn.Open strConn
' 2. 【重要】トランザクションの開始
' 複数の操作を行う場合、整合性を担保するために必須
cn.BeginTrans
' 3. CursorLocationの設定
' 更新を伴う操作では、原則として Client-side を選択する
cn.CursorLocation = adUseClient
' 4. レコードセットのオープン
' Openメソッドの引数に注意：adOpenKeyset | adLockOptimistic
' Client-side cursorと組み合わせることで、高い更新性を確保する
rs.Open "SELECT * FROM T_Inventory WHERE ID = " & targetID, cn, _
adOpenKeyset, adLockOptimistic
If Not rs.EOF Then
' 5. データの更新
rs.Fields("StockQuantity").Value = rs.Fields("StockQuantity").Value - 1
rs.Fields("LastUpdated").Value = Now()
' 更新の確定
rs.Update
' 6. トランザクションのコミット
cn.CommitTrans
Debug.Print "Update Successful."
Else
Debug.Print "Record not found."
cn.RollbackTrans
End If
CleanUp:
' 7. オブジェクトのライフサイクル管理（クローズと解放）
' エラーが発生しても必ずここを通るように設計する
On Error Resume Next
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
Exit Sub
ErrorHandler:
' 8. エラー時のロールバック
If Not cn Is Nothing Then
If cn.State = adStateOpen Then
cn.RollbackTrans
Debug.Print "Transaction Rolled Back due to error."
End If
End If
MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical, "System Error"
Resume CleanUp
End Sub4. アーキテクトからのアドバイス：設計時のチェックリスト
君が設計図を書くとき、以下の3点を自問自答してほしい。
1. データのボリュームは予測可能か？
もし数百万件のログテーブルを `adUseClient` で開こうとしているなら、その設計は破綻している。その場合は、SQL側で集計（GROUP BY）を済ませ、結果だけを最小限のレコードセットで受け取る設計に切り替えろ。
2. ネットワークのレイテンシは考慮されているか？
VPN越しやクラウド上のDBに接続する場合、`adUseServer` でレコードを1件ずつループさせて処理するのは最悪のパフォーマンスを生む。`adUseClient` で一括取得するか、あるいはストアドプロシージャ（または複雑なSQL）にロジックを寄せるべきだ。
3. 「失敗したとき」のデータの状態を定義しているか？
`Update` は成功したが、その後の `CommitTrans` で失敗した場合、データはどうあるべきか。トランザクションの範囲を最小限にしつつ、不整合を許さない設計を徹底せよ。
結論
`CursorLocation` は単なるプロパティではない。それは、「メモリ、速度、整合性」のトレードオフを制御するためのレバーである。
このレバーを正しく操れる者だけが、バグに怯えることなく、大規模で堅牢な業務システムを構築することができるのだ。
