凡庸なエンジニアを脱する「DAOカーソル」の極意：dbOpenSnapshotとdbOpenDynasetの境界線
現場で動く「ツール」を作っているだけの人間と、変化に耐えうる「システム」を設計できるエンジニアの差は、どこに現れるか。
多くの開発者は、Recordsetを開く際に「とりあえず `dbOpenDynaset` を使っておけば間違いない」と考える。更新ができるから、という理由だけでだ。しかし、その安易な選択が、データ量が増大した際のパフォーマンス低下や、マルチユーザー環境での予期せぬデッドロックを引き起こす火種になることを、彼らは理解していない。
今日は、Access VBAにおけるデータ操作の心臓部、DAOのSnapshot（スナップショット）とDynaset（ダイナセット）のアーキテクチャ的差異について、その深淵を解説する。
1. アーキテクチャの本質：写真は「静止」、映像は「動的」
まず、概念を整理しよう。この違いを理解せずにコードを書くのは、地図を持たずに航海に出るのと同じだ。
dbOpenSnapshot：データの一時的な「写し」
Snapshotは、クエリを実行した瞬間のデータ状態をメモリ上に固定（キャプチャ）したものだ。
- 性質: 読み取り専用（Read-Only）としての運用が基本。
- 挙動: 一度読み込んだら、元のテーブルが更新されても、そのRecordsetの中身は変わらない。
- コスト: 読み取り専用であるため、エンジン側で「変更検知」や「排他制御（ロック）」のための複雑な管理を行う必要がない。
dbOpenDynaset：生きたデータへの「窓」
Dynasetは、テーブルの実体と常にリンクしている「動的な集合」だ。
- 性質: 更新可能（Updatable）。
- 挙動: Recordsetを辿っている最中に他のユーザーがデータを書き換えた場合、その変更が反映される。
- コスト: エンジンは「どのレコードがどこにあるか」「誰がどのレコードをロックしているか」を常に監視し続ける必要がある。この「動的な管理」こそが、リソース消費の正体だ。
2. パフォーマンスとロックの観点からの比較
なぜ使い分けが重要なのか。それは、メモリ消費量とロックの競合という、実務上の2大リスクに直結するからだ。
| 比較項目 | dbOpenSnapshot | dbOpenDynaset |
|---|---|---|
| 主な用途 | 集計、レポート出力、参照用リスト | データ入力、一括更新、複雑なロジックによる編集 |
| メモリ負荷 | 読み込み時に一括確保（高速だが、巨大すぎるとメモリを圧迫） | 随時アクセス（カーソル移動に伴うオーバーヘッドがある） |
| ロックの影響 | 最小限。読み取り専用のため、他者の更新を妨げにくい | 高い。レコードを掴んでいる間、他者の操作をブロックする可能性がある |
| データ整合性 | 実行時点のデータに固執する（一貫性は高い） | 常に最新を追う（リアルタイム性は高い） |
プロジェクトリーダーの視点：ここが落とし穴だ
大量のデータをループで回して集計処理を行う際、すべてを `dbOpenDynaset` で開いていないか？
もしそうなら、あなたは「集計しているだけのユーザー」によって、本来の「業務入力を行っているユーザー」の操作をブロックしている可能性がある。これは業務システムとして致命的な欠陥だ。
3. 実務における「黄金律」
設計思想として、以下のルールを徹底せよ。
1. 参照・集計・検索結果の表示 $\rightarrow$ `dbOpenSnapshot` を選択せよ。
2. 値の書き換え・削除・複雑なステータス更新 $\rightarrow$ `dbOpenDynaset` を選択せよ。
3. 大量のレコードを処理する場合 $\rightarrow$ `dbOpenSnapshot` で高速に回し、更新が必要なレコードだけを `dbOpenDynaset` もしくは `UPDATE SQL` でピンポイントに叩け。
4. プロダクションレベルのコード実装例
では、これらをどのように使い分けるべきか。保守性と堅牢性を担保した実装例を示す。
例1：高速な参照処理（Snapshotの活用）
大量のマスターデータから特定の条件に合致するものを抽出する、読み取り専用のパターンだ。
''' <summary>
''' 指定した条件に合致するデータを高速に抽出する（参照専用）
''' </summary>
''' <param name="strCriteria">抽出条件（SQLのWHERE句に相当）</param>
''' <returns>抽出されたデータのRecordset</returns>
Public Function GetReferenceDataSnapshot(ByVal strCriteria As String) As DAO.Recordset
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strSql As String
Set db = CurrentDb
strSql = "SELECT ID, ItemName, UnitPrice FROM T_MasterItems WHERE " & strCriteria
' 【設計の肝】参照専用のため dbOpenSnapshot を指定。
' これにより、メモリ上のオーバーヘッドを抑え、他者の更新を阻害しない。
Set rs = db.OpenRecordset(strSql, dbOpenSnapshot, dbReadOnly)
' 呼び出し元で rs.Close が行われることを前提とする
Set GetReferenceDataSnapshot = rs
End Function例2：堅牢な一括更新処理（Dynaset + トランザクション）
データの整合性を守るため、Dynasetでの更新には必ずトランザクションを組み合わせる。これができないエンジニアは、中途半端なコードを書いていると言わざるを得ない。
''' <summary>
''' 特定の在庫ステータスを一括で更新する（更新用）
''' </summary>
''' <param name="targetCategoryId">更新対象のカテゴリID</param>
Public Sub UpdateStockStatusByCategory(ByVal targetCategoryId As Long)
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim ws As DAO.Workspace
Set ws = DBEngine(0)
Set db = CurrentDb
On Error GoTo ErrorHandler
' 【設計の肝】更新を行うため dbOpenDynaset を使用。
' トランザクションを開始し、エラー発生時に「中途半端な更新」を防ぐ。
ws.BeginTrans
Set rs = db.OpenRecordset("SELECT ID, StockStatus FROM T_Inventory WHERE CategoryID = " & targetCategoryId, _
dbOpenDynaset, dbOptimistic)
Do Until rs.EOF
rs.Edit
' ビジネスロジックに基づいた更新処理
rs!StockStatus = "Processed"
rs.Update
rs.MoveNext
Loop
' 全ての処理が正常に完了した場合のみ確定
ws.CommitTrans
Debug.Print "Update successful."
CleanUp:
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
Set db = Nothing
Exit Sub
ErrorHandler:
' エラーが発生した場合は、全ての変更をロールバック（破棄）する
ws.Rollback
MsgBox "Critical Error: Transaction rolled back. " & Err.Description, vbCritical
Resume CleanUp
End Sub5. 結言：アーキテクトとしての規律
`dbOpenDynaset` は強力だが、コストの高いツールだ。
`dbOpenSnapshot` は軽量だが、静的なデータだ。
「動けばいい」という思考で、すべてのRecordsetをDynasetで開くような設計は、システムがスケールした瞬間に崩壊する。メモリを節約し、ロックを最小限に抑え、トランザクションで整合性を担保する。
この「使い分け」こそが、プロフェッショナルな業務自動化エンジニアと、単なるプログラマーを分かつ境界線である。君のコードに、その設計思想が宿っていることを期待する。
