Access VBAで「UIフリーズ」を根絶する：QueryDefと非同期CSV出力の極意
Accessで数百万行のクエリを実行し、そのままCSVへ書き出そうとして、「応答なし」の白い画面を眺めた経験はないだろうか。
UIスレッドを占有し、OSから「死んだプロセス」と見なされる――それは、VBAを単なるスクリプト言語として扱う初心者の限界だ。真のアーキテクトは、`DoEvents`を「気休め」ではなく、プロセス制御の精密なギアとして使いこなす。
今日は、QueryDefを駆使し、メモリを枯渇させず、UIを止めずにCSVを出力する「非同期バックグラウンド処理」の深淵に触れる。
—
1. 非同期処理の核心：なぜ「DoEvents」だけでは足りないのか
多くのエンジニアが犯す過ちは、ループ内に`DoEvents`を置けば安全だと勘違いすることだ。しかし、ループが高速すぎると、今度はイベント処理のオーバーヘッドで全体のパフォーマンスが著しく低下する。
真の非同期設計においては、以下の三点を徹底せよ。
- バッチサイズの最適化: 一度に処理する行数を制御し、OSへの制御権譲渡頻度を最適化する。
- オブジェクトのライフサイクル管理: `DAO.Recordset`は必ず暗黙のバッファから解放する。
- ストリーム書き込みの効率化: `Print #`ステートメントの安易な多用はディスクI/Oをボトルネックにする。`ADODB.Stream`を活用せよ。
—
2. 実装：QueryDefとADODB.Streamによる非同期CSV出力
このコードは、巨大なレコードセットをストリーミング処理し、進捗をUIにフィードバックしつつ、メインスレッドを殺さない設計となっている。
Option Compare Database
Option Explicit
‘ メモリ最適化のための定数
Private Const BATCH_SIZE As Long = 1000
Public Sub ExportQueryToCsvAsync(queryName As String, filePath As String)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
Dim stm As Object ‘ ADODB.Stream
Dim i As Long
Set db = CurrentDb
Set qdf = db.QueryDefs(queryName)
Set rs = qdf.OpenRecordset(dbOpenSnapshot)
‘ ADODB.Streamによる高速なバイナリ書き込み
Set stm = CreateObject(“ADODB.Stream”)
stm.Type = 2 ‘ adTypeText
stm.Charset = “UTF-8”
stm.Open
Do Until rs.EOF
‘ バッチ処理単位でUIを更新
If i Mod BATCH_SIZE = 0 Then
DoEvents ‘ メインスレッドの呼吸を確保
Application.SysCmd acSysCmdSetStatus, “処理中: ” & i & “行目…”
End If
‘ カンマ区切りでバッファへ書き込み
stm.WriteText Join(ExtractFields(rs), “,”) & vbCrLf
rs.MoveNext
i = i + 1
Loop
stm.SaveToFile filePath, 2 ‘ adSaveCreateOverWrite
‘ 厳格なリソース解放
stm.Close
rs.Close
Set stm = Nothing
Set rs = Nothing
Set qdf = Nothing
Set db = Nothing
Application.SysCmd acSysCmdClearStatus
MsgBox “エクスポート完了”, vbInformation
End Sub
‘ フィールド抽出の効率化
Private Function ExtractFields(rs As DAO.Recordset) As Variant
Dim fld As DAO.Field
Dim arr() As String
ReDim arr(rs.Fields.Count – 1)
For Each fld In rs.Fields
arr(fld.OrdinalPosition) = “””” & Nz(fld.Value, “”) & “”””
Next fld
ExtractFields = arr
End Function
—
3. シニアエンジニアが着目すべき「メモリの重み」
上記のコードで最も重要なのは、`dbOpenSnapshot`を使用している点だ。`dbOpenDynaset`は変更追跡のためにオーバーヘッドが大きく、今回のような「ただ読み出すだけ」の処理には適さない。
また、`ADODB.Stream`を用いることで、ファイル操作のI/Oをメモリ上にキャッシュし、物理ディスクへの書き込み回数を最小化している。これがレガシーな `Open #1 For Output` との違いだ。
アーキテクトからの助言：
1. メモリリークを恐れるな、監視せよ: `Set Object = Nothing` はマントラだ。しかし、最も危険なのは参照の循環や、予期せぬエラーで `rs.Close` がスキップされることである。必ず `On Error GoTo` でエラーハンドラを実装し、終了処理を担保せよ。
2. Windows APIの介入: もし更なる高度な制御が必要な場合、`Sleep`関数（`kernel32`）を呼び出し、CPU使用率を意図的に落とすことで、サーバー環境でのリソース枯渇を防ぐ手もある。
結びに代えて
Accessは「おもちゃ」ではない。適切に設計されたVBAコードは、エンタープライズな業務基盤として驚異的なパフォーマンスを発揮する。
今回の非同期処理は、大規模データと対峙するための第一歩に過ぎない。君たちのシステムが、ただ動くものから、堅牢でインテリジェントなアーキテクチャへと進化することを願っている。
コードに魂を込めよ。それがエンジニアの矜持だ。
