DAO.Recordsetの「型不一致」と「ロックの深淵」：Accessアーキテクトが語るパフォーマンス最適化の極意
Access VBAで業務システムを構築する際、DAO（Data Access Objects）は依然として最強のツールである。しかし、`OpenRecordset`メソッドの引数を無自覚に省略するようなエンジニアは、爆弾を抱えて走り回っているのと同義だ。
今日は、多くのエンジニアが「なんとなく動いている」で済ませている`dbOpenDynaset`、`dbOpenSnapshot`、`dbOpenTable`の使い分けが、いかに実行速度とメモリ、そしてロック競合に影響を与えるか。その極限の知見を共有する。
1. なぜ「型指定の欠如」が命取りになるのか
`OpenRecordset`の第二引数を省略すると、Accessは接続先がローカルテーブルかリンクテーブルかを自動判定する。この「忖度」こそが、大規模システムにおいてパフォーマンスを著しく低下させる要因だ。
型指定がもたらす物理的差異
- dbOpenTable: ローカルテーブル限定。インデックスをフル活用し、最速でアクセスする。リンクテーブルでこれを使うと実行時エラーになる。
- dbOpenDynaset: 読み書き可能。双方向スクロールが可能だが、レコードセットの構築コストが高い。
- dbOpenSnapshot: 読み取り専用。静的メモリ上に展開されるため、集計やレポート生成には最適。
- dbOpenForwardOnly: 最速の読み取り専用。順方向のみ。一度読み込んだデータはメモリから破棄されるため、メモリ効率が圧倒的に高い。
「型不一致」エラーが発生するのは、大抵の場合、ロックの挙動を無視したまま更新処理を走らせ、データベースエンジンが意図しないカーソル形式を選択した結果だ。
2. 実践：メモリ最適化とトランザクションの極意
シニアエンジニアであれば、DAOオブジェクトは「使い捨て」ではなく「ライフサイクル管理」の対象であると認識しているはずだ。以下のコードは、大規模なデータ更新を行う際の定石である。
Public Sub OptimizedUpdateProcess()
Dim db As DAO.Database
Dim rs As DAO.Recordset
‘ DB参照のキャッシュ（DBエンジンを再利用する）
Set db = CurrentDb
‘ 明示的な前方専用（ForwardOnly）で読み込み、メモリ消費を最小化
‘ dbSeeChangesはSQL Server等のリンクテーブルで必須となるフラグ
Set rs = db.OpenRecordset(“SELECT FROM T_LargeData WHERE Status = 0”, _
dbOpenDynaset, dbSeeChanges)
On Error GoTo ErrHandler
db.BeginTrans ‘ トランザクション開始
Do Until rs.EOF
rs.Edit
rs!Status = 1
rs.Update
rs.MoveNext
Loop
db.CommitTrans ‘ 全更新完了
CleanExit:
‘ オブジェクトの明示的破棄（GC任せにしない）
If Not rs Is Nothing Then rs.Close: Set rs = Nothing
Set db = Nothing
Exit Sub
ErrHandler:
db.Rollback ‘ 障害時は即ロールバック
MsgBox “Critical Error: ” & Err.Description
Resume CleanExit
End Sub
3. レガシー環境とWindows APIの接点
もし、Accessの標準機能では解決できないロック競合や、OSレベルでのファイル監視が必要な場合、`Kernel32.dll`を呼び出す必要がある。
例えば、ネットワークドライブ上のmdb/accdbファイルが、他のユーザーによって強制的にロックされていないかを確認する際に、`OpenFile` APIを駆使して排他制御を検証する手法がある。これは、DAOの`dbDenyRead`や`dbDenyWrite`オプションでは検知できない、システムアーキテクト特有の「深層防護」だ。
4. アーキテクトからの提言：DAO vs ADO
DAOはAccessの心臓部であり、ローカルデータに対してはADOよりも確実に高速だ。しかし、SQL ServerやAzure SQLへの移行を見据えるなら、ADOの`Command`オブジェクトと`Parameter`を用いたスケーラブルな設計に切り替える必要がある。
- DAOを使うべき時: ローカルテーブルの操作、フォームのレコードソース、単純なCRUD。
- ADOを使うべき時: 非同期処理が必要な時、ストアドプロシージャの実行、大規模な分散トランザクション。
結びに：コードに魂を込める
Access VBAは「古い」のではない。「正しく扱える者が少なくなった」だけだ。
`dbOpenDynaset`の背後にあるカーソルエンジンの挙動を理解し、メモリを管理し、トランザクションの範囲を極限まで絞り込む。それが、伝説的なエンジニアとしての第一歩だ。次回のコードレビューでは、`OpenRecordset`の第二引数を一言も触れずに済むような実装を期待している。
技術は裏切らない。ただ、理解の浅い者を置き去りにするだけだ。
