Accessの深淵：名前の自動修正（Name AutoCorrect）という「毒」を制御する技術
Access開発の現場において、我々アーキテクトが最も忌み嫌う機能の一つが「名前の自動修正（Name AutoCorrect）」だ。
この機能は、テーブルやクエリの名称を変更した際、依存関係にあるフォームやレポート、クエリの参照先を自動追従するという「一見便利な」機能を備えている。しかし、大規模なシステムにおいて、この機能はデータベース・エンジンに対する「見えない毒」として機能する。
なぜなら、Accessは名前が変更されるたびに、隠しシステムテーブル（`MSysNameMap`など）を介してオブジェクトの依存関係を常に監視・解決し続けるからだ。これがインポート処理や大量のデータ更新、複雑なSQL発行時に発生すると、パフォーマンスの著しい低下を招き、最悪の場合、プロジェクトの破損（Corruption）という致命的な結末を迎える。
本稿では、この機能をVBAから制御し、ミッションクリティカルな処理の最中だけ「毒」を無効化する極限の知見を授ける。
—
1. 「名前の自動修正」の本質的リスク
Accessの内部アーキテクチャにおいて、名前の自動修正は「修正用ログ」を生成し続ける。特に、以下のような場面でシステムを窒息させる。
- 大量のインポート処理: テンポラリテーブルを頻繁に作成・削除する際、その都度、自動修正機能が依存関係を再評価する。
- 動的SQLの生成: レコードソースをVBAで動的に書き換える際、不要なオーバーヘッドが発生する。
- マルチユーザー環境: 共有データベースでのトランザクション衝突のトリガーとなる。
我々プロフェッショナルは、特定の処理（特にインポートや大規模データ更新）を実行する前に、この機能をプログラム的に遮断しなければならない。
—
2. GetOption / SetOption による制御の極致
Accessのグローバル設定である「名前の自動修正」は、`Application.GetOption` で取得し、`SetOption` で書き換えることが可能だ。
実装コード：安全なコンテキスト管理クラス
単に設定を切り替えるだけでは不十分だ。エラー発生時に設定が「無効」のまま放置されると、将来の修正作業に支障をきたす。必ず「例外安全（Exception Safety）」を担保せねばならない。
‘ @class clsAutoCorrectManager
‘ 目的: 名前の自動修正を一時的に無効化し、処理終了時に自動復帰させるRAII的アプローチ
Option Compare Database
Option Explicit
Private m_OriginalState As Boolean
Private Sub Class_Initialize()
‘ 現在の設定を退避（80: 名前を自動修正、81: 名前を自動修正のログ記録）
m_OriginalState = Application.GetOption(“Name AutoCorrect”)
‘ 設定が無効なら無効化（パフォーマンス最適化）
If m_OriginalState Then
Application.SetOption “Name AutoCorrect”, False
End If
End Sub
Private Sub Class_Terminate()
‘ 処理終了時に設定を復元（確実に元に戻すことが重要）
If Application.GetOption(“Name AutoCorrect”) <> m_OriginalState Then
Application.SetOption “Name AutoCorrect”, m_OriginalState
End If
End Sub
—
3. シニアエンジニアが意識すべき「メモリと整合性」の秘術
上記の設定変更を適用する際、以下の「鉄の掟」を忘れてはならない。
1. レガシー環境でのAPI活用
もし、特定の処理でAccessがハングアップしやすい環境であれば、`DoEvents`を多用するのではなく、Windows APIを使用してプロセスIDを確認し、プライオリティを制御する手法も有効だ。しかし、まずは `SetOption` による「名前の自動修正」の無効化が最優先である。
2. メモリ最適化
`CurrentDb` オブジェクトをループ内で生成してはならない。これはメモリリークの最大の要因だ。
‘ 悪い例: ループ内で生成し、キャッシュを無駄に食う
For i = 1 To 100
CurrentDb.Execute “…” ‘ 毎回DBオブジェクトを再生成している
Next
‘ 良い例: オブジェクトをキャッシュする
Dim db As DAO.Database
Set db = CurrentDb
‘ ここでクラスを呼び出し、自動修正を無効化
Dim acm As New clsAutoCorrectManager
db.Execute “…”
‘ …
Set db = Nothing
3. 破損回避のための「コンパクト修復」
どれほど完璧にコードを書いても、Accessのバイナリ構造は時間の経過とともに肥大化する。VBAから `Application.CompactRepair` をトリガーするロジックを、夜間バッチやシステム終了時に組み込むのは、現代のAccessアーキテクトの最低限の教養である。
—
結論：技術への敬意を忘れるな
「名前の自動修正」機能は、初心者がGUIで開発する分には有用だ。しかし、我々のようにAccessというプラットフォームの限界までを搾り取るエンジニアにとって、それは「制限」に過ぎない。
システムを安定稼働させるための秘訣は、Accessが良かれと思って行っている「親切なお節介」を、我々が完全に支配下に置くことにある。本稿のコードを実装し、貴殿のシステムから「不可解なエラー」という名の幽霊を追い払ってほしい。
真のアーキテクトに、偶然の成功は不要である。すべては制御可能なロジックによって構築されるべきだ。
