Access VBAのエラー処理についてお探しですね。

広告

Accessのエラー処理、ちゃんとできてますか?プロが実践する堅牢なコードの書き方

Accessで作ったツールを他の人に使ってもらったら、「なんかエラーが出て動かなくなっちゃった…」って言われて、冷や汗をかいた経験ありませんか?自分だけで使っている分には、エラーが出ても「終了」ボタンを押して再起動すれば済む話です。

でも、業務システムとして他の人が使うとなると、そうはいきません。

予期しないエラーが起きたときに、システムを強制終了させずにちゃんと処理を続けられるようにする。

しかも、後から原因を特定しやすくしておく。

これが「エラーハンドリング」という技術です。

独学でVBAを学んだ人が最初にぶつかる壁でもあり、ここを乗り越えられるかどうかが、趣味のコードと仕事で使えるコードの決定的な違いになります。

この記事では、現場で本当に使えるAccess VBAのエラー処理と、効率的なデバッグのやり方について解説していきます。

なぜエラー処理が必要なのか?システムを止めないための基本

VBAでエラーハンドリング(例外処理)をする一番の目的は、エラーメッセージを隠すことじゃありません。

「データの整合性を守って、ユーザーの仕事を止めないこと」なんです。

エラー処理が入っていないプログラムだと、何か想定外のことが起きた瞬間に、Accessの冷たいエラーメッセージがドーンと表示されて、処理が止まってしまいます。

すると、途中まで更新していたデータが中途半端な状態でテーブルに残ったり、開きっぱなしのレコードセットがメモリを食いつぶしたり…。

最悪の場合、データベース自体が壊れてしまうリスクもあります。

それに、システムを使うユーザーにとって、意味不明な英語や専門用語だらけのエラー画面って、めちゃくちゃ怖いんですよね。

「何か壊しちゃったかも…」って不安になって、システムへの信頼がガタ落ちです。

プロが書くコードでは、想定外のエラーが起きても、開いているオブジェクトをちゃんと閉じるなどの後始末(クリーンアップ)を必ず行います。

そして、「何が起きたのか」「次にどうすればいいのか」をユーザーに分かりやすく伝える設計になっています。

エラーをゼロにするのは無理ですが、エラーが起きてもシステム全体をクラッシュさせない「頑丈さ」を確保すること。

これがエラーハンドリングの本当の目的です。

「On Error」の正しい使い方、知ってますか?

Access VBAのエラー処理で基本になるのが「On Error」という命令です。

でも、これを正しく使えている人は意外と少ないんです。

一番基本で、かつ推奨されるのが「On Error GoTo ラベル名」という形です。

プロシージャ(関数や処理のまとまり)の最初に書いておいて、エラーが起きたら処理の最後にあるエラー処理専用の場所へジャンプさせる、という仕組みです。

ここで大事なのが、正常に処理が終わったときにエラー処理の場所に入り込まないように、その手前で必ず「Exit Sub(またはExit Function)」を書くこと。

こうすることで、正常な処理とエラー時の処理をはっきり分けられて、コードがすごく読みやすくなります。

“`vb
Sub データ処理()
On Error GoTo エラー処理

‘通常の処理
‘…

Exit Sub ‘←これを忘れずに!

エラー処理:
MsgBox “エラーが発生しました”
End Sub
“`

一方、よく見かける「On Error Resume Next」は要注意です。

これは「エラーが起きても無視して次の行に進む」という強力な命令。

プロの現場では、使う場所をかなり限定します。

例えば、「存在するか分からないオブジェクトを削除する」みたいな、エラーが起きても問題ないことが明らかな場所でだけ使います。

しかも、使った直後に「On Error GoTo 0」でエラー処理をリセットするのが鉄則です。

これをサボってプロシージャ全体に適用しちゃうと、本当は見つけるべき重大なバグまで見逃してしまって、原因不明の不具合を生む温床になります。

「とりあえず動くからいいや」って感覚でResume Nextを多用するのは、プロとしてはNGです。

デバッグを効率化する!イミディエイトウィンドウの活用術

エラー処理を書く前に、開発の段階でバグを潰しておくための「デバッグ技術」も大事です。

初心者の人がよくやるのが、変数の値を確認するために「MsgBox」でポップアップを表示させる方法。

でも、これって効率が悪いんですよね。

特にループ処理の中で使うと、何度もOKボタンを押さなきゃいけなくて、確認作業自体が苦痛になります。

プロは代わりに「Debug.Print」をよく使います。

VBE(Visual Basic Editor)の画面下にある「イミディエイトウィンドウ」に値を出力して確認するんです。

これなら、プログラムの実行を邪魔することなく、変数の変化や処理の流れを時系列でログみたいに確認できます。

複雑なロジックを解析するスピードが段違いに速くなりますよ。

“`vb
Debug.Print “変数Aの値: ” & A
“`

それから、「ブレークポイント(F9キー)」と「ステップ実行(F8キー)」の組み合わせも、デバッグの基本中の基本です。

怪しい箇所の行番号の左側をクリックすると、茶色い丸印(ブレークポイント)がつきます。

そこで実行を一時停止させて、F8キーで1行ずつコードを実行しながら、「ローカルウィンドウ」で変数の値がどう変わっていくかをリアルタイムで見るんです。

エラーが出た行だけ見るんじゃなくて、その前の処理で変数が意図しない値になってないか、条件分岐がちゃんと動いているかをチェックする。

これで、根本的な原因を一発で見つけられることが多いです。

こうしたVBEの標準機能を使いこなすことが、開発効率アップの鍵になります。

ユーザーに優しいエラーメッセージとログ管理のコツ

システムを運用するうえで一番大事なのが、エラーが起きたときに「開発者がいない場所でも状況が分かること」です。

ただ「エラーが発生しました」って表示するだけじゃ、ユーザーから問い合わせがあっても対応できません。

プロのコードでは、エラー番号(Err.Number)とエラー内容(Err.Description)、それから発生したプロシージャ名をセットで管理します。

ユーザー向けの画面には「お手数ですが、システム担当者にご連絡ください」みたいな丁寧なメッセージを表示しつつ、裏側ではテキストファイルや専用のログテーブルに、エラーの詳細情報や発生日時、ログインユーザー名などを自動的に記録する仕組みを作っておきます。

こうしておけば、ユーザーから連絡があったときに、開発者はログを見るだけで「いつ、誰が、どの画面で、何をしてエラーになったか」を正確に把握できます。

たまにしか起きないエラーや、特定のパソコンでだけ発生するエラーなんかは、このログ情報がないと解決の手がかりすら掴めません。

それから、エラーメッセージ自体も、ユーザーが自分で解決できるもの(例:入力漏れ、ファイルの選択ミス)と、システム的な深刻なエラー(例:SQL実行エラー、メモリ不足)で、出し分ける配慮が必要です。

エラーをただの「困ったこと」で終わらせず、システムの改善や保守運用のための貴重な情報源に変える。

そういう設計ができるかどうかが、プロフェッショナルな仕事かどうかの分かれ目になります。

まとめ

エラー処理って地味に見えますが、実は「使えるシステム」と「使えないシステム」を分ける超重要なポイントです。

最初は面倒に感じるかもしれませんが、一度身につければ、あなたの作るシステムの信頼性が格段に上がりますよ!

広告