【ep3-2】ADO接続デバッグの地獄。SQL・VBA・Accessの三つ巴で何週間も詰んだ記録

野良DB、デバッグ地獄の幕開け

当時の予算はゼロでした。与えられた武器は、各個人のパソコンにインストールされたExcelと、なぜか標準装備されていたAccessだけでした。そこから手探りでつなぎ合わせたのが、7拠点のデータを一元管理する「野良DB」です。

ファイルサーバーの奥深くにMDBファイルをひっそりと置きました。各担当者がExcel VBAのボタンを押せば、データが飛んでいく仕組みです。テスト環境での動きは完璧でした。自分が思い描いた通りにデータが格納され、集計されることに喜びを感じていました。素人が作ったシステムが会社を救う。しかし、そんな甘い幻想は、現場でのテスト稼働を始めた直後に粉々に打ち砕かれました。

稼働初日、デバッグ地獄の始まり

稼働初日の朝、自分のPCでは問題なく動きました。そのため、安心しきっていました。しかし10分後、隣の席から「マクロのボタンを押したら変な英語の画面が出た」との声がかかりました。急いで駆けつけると、見たこともない「実行時エラー」の文字がありました。心臓が跳ね上がりました。冷や汗が出たことを覚えています。自分の席では動くのに、同僚の席では動きません。その理由が全くわかりませんでした。

問題の根本は、原因が複数箇所に分散していたことにありました。VBAの記述ミスでしょうか。SQLの構文エラーでしょうか。あるいはAccess側の設定がおかしいのでしょうか。知識のない非エンジニアにとって、それは暗闇の中で目隠しをしてパズルを解くような経験でした。ADO接続が突然切れる現象も起きました。どこから手をつければよいのか、見当もつきません。まさに絶望的なデバッグ地獄の幕開けでした。

接続文字列の壁：Officeビット数とプロバイダ

最初の大きな壁は、ExcelとAccessを繋ぐための「ConnectionString（接続文字列）」でした。ADO接続（ActiveX Data Objects）を使ってExcel VBAからAccessにアクセスするには、プロバイダを指定する必要があります。それは、まるで呪文のようなコードでした。

ネットの技術ブログを見様見真似で参考にし、「Provider=Microsoft.ACE.OLEDB.12.0」と記述しました。自分の環境では問題なく動きました。しかし、別の担当者のPCでは「プロバイダが見つかりません」と冷酷に弾かれてしまいました。

ネットの情報を鵜呑みにして「Microsoft.Jet.OLEDB.4.0」に書き換えてみました。すると、今度は別の方のPCでエラーが発生しました。パニックになりながら、エラー画面をスマホで撮りました。自分の席でひたすらGoogle検索を繰り返しました。結局、2日間の業務時間のほとんどをこの1行のコードのために費やすことになりました。

Office混在環境の罠

原因は、会社のPC環境に32bit版と64bit版のOfficeが混在していたことにありました。「Microsoft.ACE.OLEDB.12.0」は新しいエンジンです。インストールされているOfficeのビット数やバージョンによって、使えるプロバイダが異なります。古い環境では「Microsoft.Jet.OLEDB.4.0」しか受け付けません。これは会社特有の罠でした。機器の入れ替え時期が部署ごとにバラバラだったからです。

Officeビット数混在の現実

エンジニアの方々にとっては常識かもしれません。しかし、経理や総務の会社員が「PCのビット数」を意識する機会はほとんどありません。同じ「Excel」というアプリを使っていても、中身のアーキテクチャが違うだけでコードが動きません。この理不尽さに、戸惑いを隠せませんでした。最終的に、エラーをキャッチしてプロバイダを切り替える分岐処理を泥臭く書き加えました。それにより何とか切り抜けました。原因特定と実装にかかった時間は約15時間です。エレガントさとは程遠い力技でしたが、まずは動かすことが至上命題でした。

たった1文字のSQL型エラー

プロバイダの問題を乗り越えても、平穏は訪れませんでした。次に立ちはだかったのは、データベースを操作するための言語「SQL」の壁です。担当者の社員番号を条件にして、特定のレコードだけを更新する処理を書こうとしました。

「UPDATE テーブル名 SET フィールド = 値 WHERE 社員番号 = 12345」というSQLをVBAから投げました。すると、「型が一致しません」と突き返されました。社員番号は明らかに数字です。それなのに、なぜ型が違うのでしょうか。半角スペースの位置を変えたり、カンマを足したりと、思いつく限りの記号を挿入してはエラーを出す作業を丸3日続けました。当時は胃が重く、食事も喉を通らないほどでした。

結局、原因は驚くほど単純なものでした。Access側のデータベース設計において、社員番号を「テキスト型」として定義していたのです。SQLの世界では、テキスト型のフィールドを検索・更新する際、値をシングルクォートで囲む必要があります。正解は「WHERE 社員番号 = ‘12345’」でした。

SQLの厳格さ、データ消去の恐怖

Excelのセルなら文字も数字もよしなに判断してくれます。しかし、データベースというものはどこまでも厳格です。たった1文字の記号の有無で、すべての処理が止まってしまいます。もしこれが「DELETE」文の条件指定ミスだったらと想像します。今でも背筋が凍る思いがします。条件が正しく解釈されません。そのため、全データが消し飛ぶ危険性すらありました。この一件以来、SQLを書くときは指先が微かに震えるようになりました。

Accessロックファイル残存による業務停止

SQLの文法エラーを乗り越えました。ようやくシステムとして形になってきた頃、最大のトラブルが発生しました。ある日の朝、出社してパソコンを開くと、チャットツールに異常な数の通知が溜まっていました。「ファイルが開けません」「書き込みエラーになります」という現場からの悲鳴でした。

共有フォルダを確認すると、Accessファイルと同じ階層に見慣れない「.laccdb」という小さなファイルがありました。誰かがAccessを直接開いているのかと思いました。そこで、全員に「すぐにファイルを閉じて！」と社内アナウンスを流しました。それでもエラーは消えません。手動でファイルを消そうとしても「使用中のため削除できません」と拒絶されました。電話が鳴り続ける中、焦りで手が震えていたのを覚えています。

幽霊ロックファイルで業務停止

Accessには、複数人で同時に使うための排他制御の仕組みがあります。誰かがデータベースにアクセスすると、自動的にロックファイル（.laccdb または .ldb）が作成されます。通常は、最後の利用者が接続を切った瞬間に消えるはずです。しかし、何らかの理由で処理が強制終了する場合があります。また、ネットワークが一瞬途切れることもありました。すると、このロックファイルが亡霊のように残り続けます。

ファイルが残っている限り、Accessは「誰かが使っている」と誤認します。そして、全員をデータベースから締め出してしまうのです。周囲にシステムの中身を知る人がいませんでした。そのため、作った本人である私にすべての責任がのしかかってきました。共有サーバーの管理画面から強制的にセッションを切断しました。手動でロックファイルを削除するまで、その日の午前中の業務は完全にストップしてしまいました。7拠点の担当者が待機を余儀なくされた時間は約2時間です。便利な自動化ツールを作ったつもりでした。しかし、現場の足を引っ張る存在になりかねません。その恐怖を味わいました。

理解不能なデバッグの快感

数週間にわたるデバッグは、まさに地獄でした。プログラミングの基礎を学んだわけではありません。私にとって、エラーメッセージをコピーしてGoogle検索に叩き込むことだけが唯一の戦術でした。

検索結果の上位に出てくるStack Overflowのやり取りを確認しました。古びたVBA専門サイトの掲示板も片っ端から開きました。そこに書かれているコードをコピーして貼り付け、実行ボタンを押します。エラーが出れば別のコードを試しました。またダメなら次のサイトへ飛びました。まさに泥臭く非効率な作業の繰り返しでした。

エラー解決の瞬間

エラーの意味がわかっても、なぜそのコードで解決するのかという「理屈」は全く理解できませんでした。それでも、何十回目かの試行で、不意にエラーが出なくなる瞬間があります。数秒後に「処理が完了しました」という自作のメッセージボックスが表示されました。そのとき、背中を覆っていた重苦しい疲労感が一気に吹き飛びました。言葉にならない歓喜が込み上げてきます。その一瞬の快感だけが、デバッグ地獄を耐え抜くための唯一の救いでした。

地獄のデバッグと野良DB：非エンジニアの誇りと成長

地獄のようなデバッグ期間を経て、ExcelとAccessを連携させた野良DBはついに安定稼働を始めました。ConnectionStringの微調整、SQLの記号の扱い、ロックファイルへの対策。血を吐くような思いで一つずつ潰したエラーの山が、結果としてシステムの堅牢性となっていきました。

このシステムはその後2年以上にわたって現場で使われ続けました。7拠点から手作業でかき集めていた月次集計の時間は劇的に短縮されました。データの不整合も消滅しました。誰にも頼まれず、予算もありませんでした。しかし、「自分が楽になりたい」という一心で手探りで作ったシステムが、会社の業務を支えている。その静かな自負が、非エンジニアである私の心の中に確かに根付いていました。

エラー解決、執念が育むスキル

エラーは怖いものです。画面が止まり、見慣れないダイアログが出るたびに心臓が縮み上がります。しかし、そのメッセージの一つ一つと向き合いました。泥にまみれながら解決策を探す過程にこそ、本物のスキルが宿るのだと感じます。意味もわからないままコピペした日々が無駄だったとは全く思いません。知識がないなら、手を動かすしかないのです。野良DBの運用を通して学んだのは、完璧なコードを書く技術ではありません。最後まで投げ出さない執念そのものでした。

関連リンクとチェックリスト

学習サービスとアンケート