【テクニカル・上級編】DAO.RecordsetのOpenRecordsetで指定する「dbOpenDynaset」と「dbOpenSnapshot」のメモリ消費比較 – Access VBA解析バイブル

Access VBA

2026.08.27

Access VBAの深淵：dbOpenDynaset vs dbOpenSnapshot メモリ管理の真実

Access VBAで大規模なデータセットを扱う際、DAOの`OpenRecordset`を漫然と記述していないだろうか。多くのエンジニアが「なんとなく」選んでいるカーソルタイプが、実はシステムのメモリフットプリントを肥大化させ、GC（ガベージコレクション）の効かないVBA環境において、アプリケーションの寿命を縮めている事実に気づいている者は少ない。

今日は、`dbOpenDynaset`と`dbOpenSnapshot`の境界線について、メモリ管理とアーキテクチャの視点から解剖する。

—

1. メモリ構造から見る「Dynaset」の代償

`dbOpenDynaset`は、更新可能なカーソルだ。これは単なるデータセットではなく、「ライブな編集チャネル」である。

双方向のオーバーヘッド: 基底テーブルへの書き戻しを可能にするため、DAOエンジンは各レコードに対して「ブックマーク」と「更新用ロック情報」を保持し続ける。
メモリの滞留: 読み取り専用の目的であっても、Dynasetを生成した瞬間に、エンジンは更新の競合解決のためのメタデータをメモリ上に構築する。
実務上のリスク: 10万件のレコードセットを開いた場合、Dynasetは単なるデータ値だけでなく、更新用の参照ポインタを大量に抱え込む。これがメモリリークのような「圧迫感」を生み、長時間の稼働でAccessのプロセスを肥大化させる主因となる。

2. なぜ「Snapshot」がエンジニアの最適解なのか

一方で、`dbOpenSnapshot`は静的なデータコピーだ。

リードオンリーの究極形: データの参照が完了した瞬間に、更新用の管理領域を一切確保しない。データはメモリ（または一時ファイル）上に構築された読み取り専用のバッファに固定される。
パフォーマンスの優位性: 更新制御のためのオーバーヘッドが皆無であるため、特にネットワーク越しのバックエンド（SQL Serverなど）に対しては、トリップ回数を最小化した効率的なフェッチが行われる。

—

3. 実践：メモリ最適化のためのレコードセット生成パターン

現場で私が推奨する、メモリを浪費しないレコードセットの生成コードを提示する。ここでのポイントは、「必要な列だけをSQLで絞り込み、Snapshotで開く」という鉄則だ。

‘ 伝説的なアーキテクトによる、メモリ効率を考慮したRecordset取得のテンプレート
Public Sub GetLargeDataOptimized()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strSQL As String

‘ メモリ最適化の第一歩：SELECT は絶対禁止。必要なカラムのみ指定する。
strSQL = “SELECT ID, CustomerName, OrderDate FROM tblOrders WHERE Status = ‘Completed'”

Set db = CurrentDb

‘ 編集の必要がない場合は、迷わず dbOpenSnapshot を選択する。
‘ dbSeeChanges はSQL Server連携時の必須オプション（最適化とは別軸の堅牢性）
Set rs = db.OpenRecordset(strSQL, dbOpenSnapshot, dbSeeChanges)

With rs
If Not .EOF Then
.MoveLast ‘ レコードカウントが必要な場合のみ実行
Debug.Print “Total Records: ” & .RecordCount
.MoveFirst

Do Until .EOF
‘ データの処理
.MoveNext
Loop
End If

‘ オブジェクトの明示的解放はVBAにおける「義務」である。
.Close
End With

Set rs = Nothing
Set db = Nothing
End Sub

4. シニアエンジニアが意識すべき「メモリの行方」

VBAのメモリ管理は、.NETやJavaのような高度なメモリ管理機構とは別物だ。`Set rs = Nothing` を記述しても、即座にOSへメモリが返却されるとは限らない。

解放の順序: `rs`を閉じてから`db`を解放する。逆順は不安定な挙動を招くことがある。
Windows APIの影: 大規模なデータ処理を行う際、Accessのメモリ使用率が異常に高騰する場合、`CompactDatabase`メソッドをプログラム内から定期的に呼び出すか、あるいは一時的に外部プロセス（VB.NETのコンソールアプリ等）へ処理を逃がすアーキテクチャへの切り替えを検討せよ。
レガシーの保守: 古いMDB/ACCDBファイルでメモリ不足が多発する場合、それはカーソルタイプの選択ミス以上に、インデックスの欠如が原因であることが多い。Snapshotで開く際も、WHERE句の列には必ずインデックスを貼っておくこと。これが物理I/Oを減らし、結果としてメモリの滞留時間を短縮する。

結びに代えて

「とりあえずDynaset」という妥協が、数年後のシステム障害のトリガーになる。
Snapshotを選択することは、単なるプログラミングのテクニックではなく、「このデータは変更されない」というアーキテクトとしての意思表示だ。

コードは嘘をつかない。メモリの挙動を支配し、計算機リソースの限界までAccessを使い倒せ。それが、レガシーと最先端の狭間で戦う我々の矜持である。