【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」しか受け付けない。機器の入れ替え時期が部署ごとにバラバラな会社特有の罠だった。

一方で、エンジニアにとっては常識なのかもしれないが。経理や総務の会社員が「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の構築と運用を通して学んだのは、完璧なコードを書く技術ではなく。最後まで投げ出さない執念そのものだった。

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

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