Access VBAを掌握する極限の知見：DoCmd.TransferSpreadsheetのエラー検知と例外自動化の全貌
レガシーシステムの深部において、外部からのExcelデータ取り込みは、常に予期せぬ例外との戦いである。
`DoCmd.TransferSpreadsheet` は、一見すると極めてシンプルで強力なインターフェースに見える。しかし、実務の現場――数メガバイトに及ぶ巨大なワークシート、突如混入する型違いのセル、NULLが許容されないフィールドへの空値の挿入――において、このメソッドは無言で膝を屈する。
Accessは、インポート時にエラーが発生した際、容赦なく「インポート エラー」という名の物理テーブルをバックエンドに生成し、処理を続行（あるいは中断）する。この「自動生成されたエラーテーブル」を放置することは、データ整合性の観点からエンジニアとしての致命傷であり、システム運用の信頼性を著しく失墜させる。
本稿では、このインポートエラーの発生をVBAコードのレイヤーで完全に掌握し、動的な監視、構造解析、そしてユーザーへの優美かつ堅牢なフィードバックループを構築する極限のプラクティスを提示する。
—
1. エラー生成メカニズムの深層とアーキテクチャの設計思想
`TransferSpreadsheet` が実行される時、Jet/ACEデータベースエンジンはメモリ上でスキーマの検証を行う。ここでデータ型の一致や主キー制約、バリデーションルールに違反するレコードが検出されると、エンジンはトランザクションの一部を破棄し、該当レコードを「[対象テーブル名] $」のような形式、あるいは単純に「インポート エラー」という名称のテーブルとして物理的に実体化させる。
ここで重要なのは、「エラーが発生してもVBAの実行時エラー（Errorトラップ）が発生しない場合がある」という点だ。エラーは「データ側の例外」として扱われ、VBAの `On Error` 構文の網をすり抜けて処理が完了してしまう。
したがって、シニアエンジニアが実装すべきアーキテクチャは以下の3段階に集約される。
1. 事前クリーンアップ: 過去のインポート試行で残存した幽霊のようなエラーテーブルのパージ。
2. トランザクション的実行: `TransferSpreadsheet` の呼び出し。
3. 事後監視と解析: 発生したエラーテーブルの存在確認、スキーマ解析、および構造化されたログへの昇華。
—
2. 実装コード：堅牢性とメモリ最適化の極み
以下に、実務の現場で即座に稼働させうる、オブジェクトのライフサイクル管理を徹底したプロダクションクオリティのコードを示す。`CurrentDb` の安易な多用を避け、DAOオブジェクトの参照を確実に解放するメモリ最適化のイディオムに注目してほしい。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 外部Excel取込＆インポートエラー自動監視・例外処理モジュール
‘ ==============================================================================
Public Sub ExecuteResilientImport(ByVal strFilePath As String, ByVal strTargetTable As String)
const MODULE_NAME As String = “ModSpreadsheetImport”
‘ DAO / ADODB 関連オブジェクトのスコープ宣言
Dim db As DAO.Database
Dim tdef As DAO.TableDef
Dim rstError As DAO.Recordset
Dim strErrorTableName As String
Dim bErrorTableFound As Boolean
Dim lngErrorCount As Long
On Error GoTo ErrorHandler
‘ データベース参照の取得（CurrentDbの毎回評価を避ける）
Set db = CurrentDb()
‘ 1. 事前準備：既存のインポートエラーテーブルのクリーンアップ
‘ Accessはエラー発生時に「インポート エラー」または「[テーブル名] エラー」を生成する
Call PurgeExistingErrorTables(db)
‘ 2. トランザクション的データインポートの実行
‘ ※今回は例としてリンクではなくインポート（acImport）を採用
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12Xml, strTargetTable, strFilePath, True
‘ 3. エラーテーブルの動的検出
‘ 生成される可能性のあるエラーテーブル名をスキャン
strErrorTableName = FindImportErrorTable(db, strTargetTable)
If strErrorTableName <> vbNullString Then
bErrorTableFound = True
‘ エラーレコードの件数と詳細を解析
Set rstError = db.OpenRecordset(strErrorTableName, dbOpenSnapshot)
If Not (rstError.EOF and rstError.BOF) Then
rstError.MoveLast
lngErrorCount = rstError.RecordCount
End If
‘ ログテーブルへの退避とユーザー通知処理へ
Call ProcessImportExceptions(db, strErrorTableName, lngErrorCount, strTargetTable)
‘ エラーテーブルの破棄（次回実行への影響を防ぐ）
db.TableDefs.Delete strErrorTableName
MsgBox “データ取り込みは完了しましたが、” & lngErrorCount & ” 件のインポートエラーが検出されました。” & vbCrLf & _
“詳細はシステムログテーブルを確認してください。”, vbExclamation, “インポート警告”
Else
MsgBox “外部データの取り込みが正常に完了しました。”, vbInformation, “処理成功”
End If
CleanUp:
‘ 4. オブジェクトの明示的解放（メモリリークの完全阻止）
If Not rstError Is Nothing Then
rstError.Close
Set rstError = Nothing
End If
Set db = Nothing
Exit Sub
ErrorHandler:
‘ VBAランタイムエラーの捕捉
MsgBox “予期せぬ致命的エラーが発生しました。” & vbCrLf & _
“Error Code: ” & Err.Number & vbCrLf & _
“Description: ” & Err.Description, vbCritical, MODULE_NAME
Resume CleanUp
End Sub
‘ ==============================================================================
‘ 補助関数：生成されたエラーテーブルの特定
‘ ==============================================================================
Private Function FindImportErrorTable(ByRef db As DAO.Database, ByVal strBaseTable As String) As String
Dim tdef As DAO.TableDef
Dim strFound As String
strFound = vbNullString
‘ TableDefsコレクションを走査し、インポートエラーの命名規則に一致するものを探す
For Each tdef In db.TableDefs
If tdef.Name = “インポート エラー” Or _
tdef.Name = strBaseTable & ” エラー” Or _
InStr(1, tdef.Name, “インポート エラー”, vbTextCompare) > 0 Then
strFound = tdef.Name
Exit For
End If
Next tdef
FindImportErrorTable = strFound
End Function
‘ ==============================================================================
‘ 補助関数：既存エラーテーブルのパージ
‘ ==============================================================================
Private Sub PurgeExistingErrorTables(ByRef db As DAO.Database)
Dim tdef As DAO.TableDef
Dim i As Long
‘ コレクションのインデックス破壊を防ぐため逆順ループ
For i = db.TableDefs.Count – 1 To 0 Step -1
Set tdef = db.TableDefs(i)
If InStr(1, tdef.Name, “インポート エラー”, vbTextCompare) > 0 Or _
InStr(1, tdef.Name, ” エラー”, vbTextCompare) > 0 Then
‘ システムテーブルや意図しないテーブルを誤削除しないよう厳格にガード
If tdef.Name Like “エラー” Then
db.TableDefs.Delete tdef.Name
End If
End If
Next i
Set tdef = Nothing
End Sub
‘ ==============================================================================
‘ 例外データの永続化処理（構造化ログへの昇華）
‘ ==============================================================================
Private Sub ProcessImportExceptions(ByRef db As DAO.Database, ByVal strErrTable As String, ByVal lngCount As Long, ByVal strTarget As String)
Dim strSQL As String
‘ 例：エラー内容を監査用ログテーブル（Sys_ImportErrors）にINSERT SELECTで退避
‘ ※Sys_ImportErrorsテーブルが事前に定義されている前提
strSQL = “INSERT INTO Sys_ImportErrors ( ErrorTimestamp, TargetTable, ErrorDescriptionRecord, SourceErrorTable ) ” & _
“SELECT Now(), ‘” & Left$(strTarget, 50) & “‘, , ‘” & strErrTable & “‘ FROM [” & strErrTable & “];”
On Error Resume Next
db.Execute strSQL, dbFailOnError
If Err.Number <> 0 Then
‘ ログ書き込み自体が失敗した場合のフォールバック（イミディエイト窓への出力など）
Debug.Print “Failed to archive import errors: ” & Err.Description
End If
On Error GoTo 0
End Sub
—
3. チーフアーキテクトが説く、実運用における極意
上記のコードベースは、単なるサンプルの域を超え、エンタープライズ環境での稼働に耐えうる設計思想を取り入れている。ここで、コードの背後にある「極限の知見」をいくつか補足しよう。
オブジェクトライフサイクルの厳格な管理
Access VBAにおける最大のメモリリーク要因は、`CurrentDb` や `Recordset` の解放漏れ、そして不適切なスコープ設定である。ループ内での `CurrentDb` の呼び出しは、内部で新しいセッションとメモリ領域を毎回アロケーションするため、ガベージコレクションのタイミング次第でAccess全体の肥大化（Bloat）を招く。プロシージャの冒頭で一度変数にバインドし、終了時に必ず `Nothing` を代入する作法は、VBAエンジニアにとっての絶対律である。
コレクション走査の罠と逆順ループ
`TableDefs` や `Fields` といったDAOのコレクションを操作する際、要素の削除を伴う処理で `For Each` や正順の `For i = 0 To Count – 1` を用いると、インデックスのズレによる実行時エラー（あるいは要素のスキップ）が発生する。コレクション操作における「逆順ループ（Step -1）」は、レガシー環境における鉄則中の鉄則である。
エラー情報の永続化（監査証跡）
「インポートエラーテーブル」は、Accessを閉じたり次のインポートを実行したりすると消失、あるいは上書きされる儚い存在だ。これを `Sys_ImportErrors` のような永続的なログテーブルに `INSERT SELECT` でキャプチャしておくことで、「どのユーザーが、いつ、どのような不正データを持ち込もうとしたか」の完全な監査証跡（Audit Trail）が完成する。システム管理者は、このログを元にデータ提供元へ差し戻しの要求を行うことができる。
—
結言
Access VBAは、しばしば「おもちゃのプログラミング言語」と揶揄されることがある。しかし、それは言語の限界ではなく、書き手のアーキテクチャに対するリテラシーの欠如に起因するものでしかない。
メモリの動的管理、例外の多層防御、そして暗黙的に生成されるシステム内部構造（エラーテーブル）の徹底的な掌握。これらをコードに昇華させた時、Accessはレガシーの枠を超え、極めて堅牢なミドルウェアとして機能し始める。
真のエンジニアリングとは、枯れた技術の深淵を誰よりも深く見つめ、その不完全さをコードの美しさで完全に包み込むことにある。
