【Access VBA】実行時エラーを「未然に防ぐ」技術：AllTablesによる動的制御の真髄
業務自動化の現場で、初心者が最も陥りやすい罠がある。それは、「テーブルが存在することを前提にしたコード」を書くことだ。
「リンクテーブルが切れている」「一時テーブルを削除した後に再実行する」……こうした事態でプログラムが強制終了し、ユーザーを路頭に迷わせるシステムは、プロの成果物とは呼べない。
今回は、Accessオブジェクトモデルの深淵にある `Application.CurrentData.AllTables` を駆使し、「エラーハンドリングに頼らず、そもそもエラーを起こさない」堅牢なアーキテクチャの構築法を伝授する。
—
1. なぜ「On Error Resume Next」で誤魔化してはいけないのか
多くの開発者は、存在チェックを怠り、エラーが発生した瞬間に `On Error Resume Next` で強引に握りつぶす。これは百害あって一利なしだ。
- 予期せぬ障害の隠蔽: 権限不足や排他ロックなど、本来知るべき致命的なエラーまで無視してしまう。
- デバッグの困難さ: どこで処理が中断されたのかが不明瞭になり、保守性が地に落ちる。
真のエンジニアは、「不確実なリソースに対しては、実行前にその存在を確認する」という防御的プログラミングを徹底する。
—
2. AllTables オブジェクトによるスマートな存在判定
`Application.CurrentData` は、データベースの構造的リソースを管理する入り口だ。その中の `AllTables` コレクションを走査することで、Access内の全テーブル（リンクテーブル含む）のメタデータに高速でアクセスできる。
以下のコードは、テーブルの存在を確認し、なければ新規作成、あれば削除して再構築するという、実務で頻出する「初期化ロジック」のテンプレートだ。
実践：堅牢なテーブル存在確認と動的処理
‘ —————————————————————————
‘ 関数名: EnsureTableExists
‘ 目的: テーブルの存在を動的に確認し、存在しない場合はエラーを回避して分岐する
‘ —————————————————————————
Public Sub ManageTemporaryTable()
Dim tblName As String
tblName = “tmp_WorkData”
‘ CurrentData.AllTables で存在を確認
‘ 存在すればループを抜ける論理構成
If IsTableExists(tblName) Then
Debug.Print “テーブル存在確認: 既存のテーブルを削除して再構築します。”
DoCmd.DeleteObject acTable, tblName
End If
‘ ここでテーブル作成処理へ
Debug.Print “テーブルの再構築を開始します。”
‘ DoCmd.RunSQL “CREATE TABLE …”
End Sub
‘ —————————————————————————
‘ 汎用関数: テーブル存在チェック (論理判定)
‘ —————————————————————————
Public Function IsTableExists(ByVal strTableName As String) As Boolean
Dim obj As AccessObject
‘ AllTablesコレクションを走査
For Each obj In Application.CurrentData.AllTables
If obj.Name = strTableName Then
IsTableExists = True
Exit Function
End If
Next obj
IsTableExists = False
End Function
—
3. なぜ「CurrentDb.TableDefs」ではなく「AllTables」なのか
ここで鋭い読者は思うだろう。「`CurrentDb.TableDefs` でもチェックできるのではないか？」と。
確かに機能的には可能だ。しかし、`TableDefs` はデータベースのスキーマ情報を詳細に保持しているため、ネットワーク越しのリンクテーブルに対してアクセスすると、接続が確立され、パフォーマンスが著しく低下することがある。
一方、`CurrentData.AllTables` は、あくまで「名前」と「型」というメタデータに特化している。「存在するかどうか」を知るだけであれば、これ以上の適任はいない。 軽快で、かつ安全。これがプロの選択だ。
—
4. プロダクションコードにおける注意点
この設計をさらに昇華させるための、実務的なTipsを共有する。
- 排他制御の考慮: `AllTables` で存在を確認しても、その直後に他のユーザーがテーブルを削除する可能性がゼロではない。実務では、「テーブル削除」の操作自体には最低限の `Err.Number` 判定（エラー番号3211など）を組み合わせるのが、究極の防御となる。
- 名前の正規化: `strTableName` を引数で受け取る際は、必ず `Trim()` をかけ、不要なスペースによる誤判定を防ぐこと。
- 保守性の向上: テーブル名は定数（`Const`）または外部設定ファイルで管理すること。ハードコーディングは、未来の自分を苦しめる最大要因だ。
—
最後に：コードは「対話」である
VBAを単なる「自動化ツール」として扱うのか、それとも「堅牢なソフトウェア」として構築するのか。その違いは、こうした細部へのこだわりによって生まれる。
「エラーを捕まえる」のではなく、「エラーが起きない境界線を描く」。
この設計思想をインストールできたなら、あなたの書くプログラムは、明日から一段と安定したものになるはずだ。
さあ、コードを書き換えろ。あなたのシステムが、誰のストレスにもならないために。
