Accessのエラーについてお探しですね。
広告
Accessのエラーに出会っても慌てないために
仕事でMicrosoft Access(アクセス)を使っていて、突然見たことのないエラーメッセージが出てきて困った経験はありませんか?Accessは、データをきちんと管理するためのツールなので、Excelなんかと比べるとエラーメッセージが出る回数が多めです。
しかも、内容が専門的でちょっと難しく感じることもあります。
特に「実行時エラー」とか、番号だけがズラッと表示されたりすると、「え、どうすればいいの…?」となって、作業が完全にストップしてしまうこともありますよね。
でも安心してください。
Accessのエラーには必ず「原因」と「パターン」があります。
エラーメッセージは、データベースが壊れないようにシステムが出してくれている警告なんです。
正しい手順を踏めば、ほとんどの場合は解決できます。
この記事では、よく出てくるエラーメッセージの意味や、エラー番号ごとの具体的な対処法、さらにはデータベース本体が壊れてしまったときの修復方法まで、まとめて解説していきます。
困ったときの辞書代わりに使ってもらえたら嬉しいです。
Accessでエラーが出る主な3つの理由
Accessでエラーが起きる原因は、大きく分けて「データ」「プログラム」「環境」の3つに分けられます。
まず1つ目は**「データ」の問題**です。
テーブルで決めた「データ型」と、実際に入力した内容が合っていないときに起こります。
たとえば、数字しか入れられないところに文字を入れようとしたり、日付の欄に変な形式で日付を書いたりすると、Accessは「それはダメ!」とエラーを返してきます。
2つ目は**「プログラム(VBAやマクロ)」の書き間違い**です。
ボタンを押したときに自動で何かが動くように設定している場合、その裏で動いているコードに間違いがあると「実行時エラー」が出ます。
特に、変数の使い方が間違っていたり、存在しないものを呼び出そうとしたりすると、よくエラーになります。
3つ目は**「環境やファイル自体」の問題**です。
Accessのファイル(.accdbや.mdb)を、ネットワーク越しに複数の人が同時に使っていると、通信が途切れたり、操作がぶつかったりして不安定になることがあります。
最悪の場合、ファイル自体が壊れて「認識できないデータベース形式です」なんていう深刻なメッセージが出ることも。
まずは、今出ているエラーがこの3つのどれに当てはまるのかを考えてみると、解決の糸口が見えてきます。
【エラー番号なし】よく見るメッセージと対処法
Accessを使っていると、エラー番号が出ないで、日本語の文章だけで警告が表示されることがよくあります。
これらは主に、データを入力したり保存したりするときに出てくる警告です。
特によく見かけるのが**「レコードへの変更を保存できませんでした」**というメッセージではないでしょうか。
このエラーが出たときは、多くの場合「主キーが重複している」か「必須項目が空欄のまま」になっています。
主キーというのは、たとえばID番号のように「絶対に重複しちゃダメ」と設定されている項目のこと。
すでに登録されている番号をもう一度入力しようとすると、Accessは「それはダメです」と保存を拒否します。
また、**「値の要求」というウィンドウが勝手に出てくる**場合は、クエリの中に存在しないフィールド名が書かれている可能性が高いです。
さらに、複数人で使っている環境でよく出るのが**「データを変更できません。
別のユーザーが使用しています」**というメッセージです。
これは、あなたが編集しようとしているレコードを、ちょうど同じタイミングで誰かほかの人が編集している(またはロックしている)状態を表しています。
こんなときは無理に操作を続けようとせず、いったんフォームを閉じるか、少し時間を置いてからもう一度試してみるのが安全です。
焦って強制終了すると、データがおかしくなる恐れがあるので、落ち着いて対応しましょう。
【エラー番号別】よく出る実行時エラーコード解説
VBA(マクロ)を使っている環境では、特定の「エラー番号」と一緒に処理が止まることがあります。
ここでは、実際によく遭遇するエラーコードをいくつか紹介します。
まず、**「実行時エラー ’13’: 型が一致しません」**は、最もよく見るエラーの一つです。
これは、数字を入れるはずの変数に文字を入れようとしたり、テキストボックスの値をそのまま計算に使おうとしたりしたときに起こります。
データの受け渡し部分を見直して、CLngやCStrといった関数を使ってデータ型をはっきり変換してあげると解決します。
次に多いのが、**「実行時エラー ’94’: Nullの使い方が不正です」**です。
Accessでは、何も入力されていない状態を「Null」として扱いますが、VBAの普通の変数はNullを受け入れられません。
このエラーが出たときは、Nz関数を使って「もしNullなら空文字(””)や0に変換する」という処理を挟むのが定番の対処法です。
また、データベースとの連携でよくあるのが**「実行時エラー ‘3021’: カレントレコードがありません」**や、**「実行時エラー ‘3078’: 入力テーブルまたはクエリが見つかりません」**といった参照系のエラーです。
これらは、処理しようとしているデータが0件だったり、テーブル名のスペルミスがあったり、削除されたテーブルを呼び出そうとしたりしたときに発生します。
コードを直すときは、まず対象のオブジェクトがちゃんと存在するか確認して、データ件数が0の場合の分岐処理(If文)を追加すると回避できます。
データベースが壊れたかも?というときの「最適化と修復」
もし**「データベースの形式を認識できません」**とか**「ファイルが破損している可能性があります」**といったメッセージが出た場合、それは個別の操作ミスではなく、Accessファイル自体がダメージを受けている深刻な状態です。
こんなときにまず試してほしいのが、Accessに最初から入っている**「データベースの最適化と修復」**という機能です。
この機能は、ファイルの内部構造を整理し直して、膨らんでしまったファイルサイズを圧縮してくれます。
同時に、軽い破損なら自動で修復もしてくれる優れものです。
使い方はとても簡単で、Accessのリボンメニューから[データベースツール]タブを選んで、[データベースの最適化と修復]ボタンをクリックするだけです。
ただし、ファイルが完全に開けない状態だと、この操作すらできない場合があります。
そんなときは、Accessのソフト自体を単体で起動して(ファイルを開かずに)、メニューから対象のファイルを選んで修復を試みる方法があります。
それでもダメなら、新しい空のデータベースファイルを作って、そこへ壊れたファイルからテーブルやフォームなどのオブジェクトを全部「インポート」するという手段も有効です。
こうしたファイル破損は、無線LANで使っていたり、強制終了を繰り返したりすると起きやすくなります。
万が一修復できなかったときのために、日頃から定期的にバックアップを取っておくことが、業務を守るための最大の防御策です。
定期的なバックアップと合わせて、エラーメッセージが出たときは「いつ」「何をしたときに」出たのかをメモしておく習慣をつけると、トラブル解決のスピードがグッと上がります。
この記事を、困ったときの味方として活用してもらえたら幸いです。
広告
