Accessの「画面フリーズ」事故を撲滅せよ：Application.Echoを制御する堅牢なクラス設計
Access VBAでの大量データ処理中、パフォーマンス向上のために `Application.Echo False` を多用するのは常套手段だ。しかし、ここで一つの大きな罠がある。「エラーが発生した際、EchoがFalseのまま復帰しない」という悲劇だ。
画面が真っ白、あるいは更新されないまま放置されたAccess。ユーザーは「フリーズした」と勘違いし、タスクマネージャーから強制終了する。その結果、トランザクションが中途半端に残り、データ整合性が崩れる……。
これは技術者の不作為が生んだ事故だ。今日は、クラスのライフサイクルをハックし、どんな例外にも屈しない「自動復帰型Echo制御」の極意を伝授する。
—
なぜ「手続き型のEcho制御」は失敗するのか
多くの開発者は以下のように書く。
‘ 悪い例：エラーハンドリングが散漫
Application.Echo False
On Error GoTo Err_Handler
‘ 重い処理
…
Application.Echo True
Exit Sub
Err_Handler:
Application.Echo True ‘ ここを通らない可能性がある
MsgBox Err.Description
このコードの敗因は「責任の所在が曖昧」なことだ。エラーハンドラが複雑化すればするほど、`Application.Echo True` が実行されないパスが必ず生まれる。
オブジェクト指向の鉄則として、「リソースの解放は、そのリソースを確保したオブジェクトの寿命（ライフサイクル）に委ねるべき」である。
—
解決策：AutoEchoクラスによる自動管理
クラスモジュールの `Class_Terminate` イベントを活用する。このイベントは、インスタンスがスコープから外れた瞬間に、「エラーの有無に関わらず必ず」呼び出される。これこそが、堅牢なシステム構築の鍵だ。
実装コード：`clsAutoEcho`
まずはクラスモジュールを新規作成し、名前を `clsAutoEcho` とし、以下のコードを貼り付けてほしい。
‘ クラス名: clsAutoEcho
Option Compare Database
Option Explicit
Private Sub Class_Initialize()
‘ インスタンス生成と同時に描画停止
Application.Echo False
End Sub
Private Sub Class_Terminate()
‘ インスタンスが破棄される際、確実に画面更新を再開する
‘ エラーで処理が中断されても、ローカル変数が破棄される過程で必ず呼ばれる
Application.Echo True
End Sub
—
プロダクション環境での運用
使い方は極めてシンプルだ。処理の冒頭でこのクラスをインスタンス化するだけでいい。
Public Sub ProcessLargeData()
‘ 処理スコープ内でインスタンスを保持
Dim objEcho As clsAutoEcho
Set objEcho = New clsAutoEcho
‘ これ以降、エラーが発生しようが処理が終了しようが
‘ プロシージャを抜ければ自動的に画面更新が復帰する
‘ — 重い処理の記述 —
DoCmd.RunSQL “…”
‘ ——————–
‘ 意識的に制御したい場合は Set objEcho = Nothing で即時復帰も可能
End Sub
この設計が優れている理由
1. 認知負荷の低減: `On Error` のたびに `Echo True` を書く必要はもうない。忘れるというヒューマンエラーそのものを排除できる。
2. ネストへの耐性: 複数のプロシージャが呼び出される場合でも、呼び出し元のスコープが維持されていれば、意図したタイミングで確実に制御される。
3. 可読性の向上: 処理のロジックと「インフラ的な描画制御」を明確に分離できる。
—
アーキテクトからの助言：さらなる高みへ
この `clsAutoEcho` をベースに、さらに「マウスカーソルの砂時計制御」も組み込むことを推奨する。
`Class_Initialize` で `DoCmd.Hourglass True` を実行し、`Class_Terminate` で `False` に戻す。これを `clsAccessManager` のような名前に拡張すれば、Accessのパフォーマンスとユーザー体験（UX）を司る強力なガーディアンが完成する。
注意点：デバッグ時の罠
開発中、イミディエイトウィンドウ等で変数をクリアする際、クラスが破棄されて画面が復帰してしまうことがある。これは「正常な動作」だが、慣れるまでは少し驚くかもしれない。だが、それこそが「システムが死なないための安全装置」が機能している証拠だ。
コードは「書く」ものではなく「設計する」ものだ。Accessの脆弱性を熟知し、それを設計でねじ伏せる。その姿勢こそが、真のエンジニアリングである。
さあ、あなたのコードから「エラー後の画面フリーズ」を完全に駆逐してほしい。
