DAO.Recordsetの深淵：`dbOpenSnapshot`と`dbOpenDynaset`のメモリ構造と実戦的選択基準
Access VBAによるエンタープライズシステムの構築において、データアクセスレイヤーの性能を左右する最大のファクターは、`DAO.Recordset`のオープンモードの選択である。
特に、数百万件規模のトランザクションデータを扱う現場において、`dbOpenDynaset`と`dbOpenSnapshot`の選択を誤ることは、アプリケーションの死を意味する。メモリリーク、Jet/ACEエンジンのロック競合、そして不必要なページファイルの肥大化。これらはすべて、オブジェクトモデルの挙動に対する無知から生じる。
本稿では、両者の内部動作とメモリ消費のメカニズムを解剖し、現場で即座に適用すべき最適解を提示する。
—
1. 内部アーキテクチャの比較：Dynaset vs Snapshot
まず、Accessの背後で稼働するデータベースエンジン（Microsoft Access Database Engine / 旧Jet）が、メモリとディスク上で何を行っているかを理解しなければならない。
`dbOpenDynaset`（ダイナセット）
ダイナセットは、「更新可能なレコードの動的集合」である。
- 構造: テーブルの実データへのポインタ（ブックマーク）と、キャッシュされたデータページのハイブリッド。
- ロック機構: 編集時には楽観的ロック（あるいは悲観的ロック）が適用され、他ユーザーの変更を検知するためのオーバーヘッドが発生する。
- メモリ消費: 高い。レコードセットが開かれている間、エンジンは変更を追跡するための内部構造（ロッキングテーブルや変更通知のリスナー）を維持し続ける。
`dbOpenSnapshot`（スナップショット）
スナップショットは、「作成された瞬間のデータの静的な静止画（読み取り専用）」である。
- 構造: クエリ結果を一時的なストレージ（メモリ、またはそれが溢れた場合はローカルのTempファイル）に完全シリアライズして保持する。
- ロック機構: 完全な読み取り専用であるため、排他制御やロックのオーバーヘッドは一切存在しない。
- メモリ消費: データ量に完全に比例する。小〜中規模データであれば極めて高速だが、数百万件規模をメモリ上に展開しようとすれば、あっという間にシステムのリソースを枯渇させる。
—
2. パフォーマンスとメモリのトレードオフ：実務的ベンチマークの知見
「データを更新しないのだから、何でもかんでもスナップショットにすれば速い」という神話は、大規模データの前では崩壊する。
| 評価項目 | `dbOpenDynaset` | `dbOpenSnapshot` |
| :— | :— | :— |
| 全件走査（ForwardOnly含む）の速度 | 遅い（オーバーヘッドあり） | 極めて高速（キャッシュが効く場合） |
| メモリ消費量（大容量時） | 比較的安定（ポインタ中心） | 爆発的に増加（データ実体を保持） |
| ネットワーク負荷（C/S環境） | 高い（逐次同期） | 最初の一括取得で完了 |
| 更新の可否 | 可能 | 不可 |
罠：巨大データのSnapshot化
100万件のレコードを持つテーブルに対して `dbOpenSnapshot` を実行した場合、Jetエンジンは一時ファイルを激しくスワップし、ディスクI/Oのボトルネックを引き起こす。この場合、必要な列だけに絞った `dbOpenDynaset` や、そもそもSQLの集計・サーバーサイド処理に逃げる方がメモリ効率が良いケースが存在する。
—
3. 【実践コード】極限まで最適化されたデータ処理パターン
以下のコードは、数万件以上のレコードを安全かつ高速に走査し、メモリリークを完全に排除するための模範的なパターンである。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 処理名: ProcessLargeScaleData
‘ 概要 : 大規模データ処理におけるRecordsetの最適ライフサイクル管理
‘ 備考 : 読み取り専用処理には必ず dbOpenSnapshot と dbForwardOnly を併用する
‘ =========================================================================
Public Sub ProcessLargeScaleData()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strSQL As String
‘ CurrentDbの直接参照はメモリリークの温床となるため、変数に格納してスコープを制御する
Set db = CurrentDb()
‘ 必要な列のみを抽出し、ネットワーク帯域とメモリを節約する（SELECT の禁止）
strSQL = “SELECT CustomerID, OrderDate, Amount FROM T_Orders WHERE OrderDate >= #2023-01-01#;”
On Error GoTo ErrorHandler
‘ 【極重要】読み取り専用かつ前方スクロールのみに限定することで、
‘ エンジンのキャッシュ構築コストを極限まで削ぎ落とする
Set rs = db.OpenRecordset(strSQL, dbOpenSnapshot, dbForwardOnly)
‘ レコードが存在しない場合のハンドリング
If rs.EOF Then
MsgBox “対象データが存在しません。”, vbInformation
GoTo Cleanup
End If
‘ 高速バルク処理のシミュレーション
Do While Not rs.EOF
‘ 業務ロジック（例：ログ出力や外部API連携など）
‘ Debug.Print rs!CustomerID, rs!Amount
rs.MoveNext
Loop
Cleanup:
‘ ———————————————————————
‘ オブジェクトの明示的解放（メモリリーク防止の鉄則）
‘ ———————————————————————
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not db Is Nothing Then
Set db = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Resume Cleanup
End Sub
—
4. シニアエンジニアが守るべき設計の鉄則
1. `CurrentDb` のチェーンを絶て
`CurrentDb.OpenRecordset(…)` という書き方は、背後で生成されたデータベースオブジェクトが暗黙的に残り続け、Access VBAにおけるメモリリークの主原因となる。必ず `Dim db As DAO.Database: Set db = CurrentDb()` としてスコープを明示的に管理せよ。
2. `dbForwardOnly` との組み合わせ
`dbOpenSnapshot` を使用する際、後ろに戻る必要（`MovePrevious` など）がないのであれば、必ず `dbForwardOnly` を同時に指定すること。これにより、レコードセットのキャッシュ構造が完全にバイパスされ、理論上の最高速度と最低メモリ消費を達成できる。
3. 書き込みが発生するなら迷わず `dbOpenDynaset`
「ループ内で値を更新する」「新規レコードを追加する」という要件がある場合、スナップショットを開いた時点で更新は不可能（エラーとなるか、書き込みが無視される）になる。更新系は `dbOpenDynaset` 一択である。
結論
`dbOpenSnapshot` は「銀の弾丸」ではない。その特性――すなわち「一時点のデータを静的にメモリ/ディスクへ焼き付ける」挙動を正確に把握していなければ、システムは突然のメモリ不足（Out of Memory）に沈むことになる。
データのライフサイクル、読み取りか更新か、そしてデータ量。これらを冷徹に見極め、コードの隅々にまで意図を宿すことこそが、真のプロフェッショナルエンジニアの仕事である。
