データ管理にとても便利な「access」ですが、たまに『何で！？』というエラーが出ることがあります。
意外にデリケート。
本日は、突然「式で型が一致しません」というエラーが出て、マクロが動かなくなったり、クエリデザインが開かなくなった時に確認する事を記事にしています。
以下の事に、心当たりがある方は、読んでみて下さい。
修正作業の前は、必ずバックアップを取ってくださいね。
データさえ生きていれば、何とかなりますから。
✓ 今まで動いていたのに、ある日突然このエラーが出た。
✓ ユニオンクエリを使用している。
✓ そういえば、最近元テーブルのフィールド名を変更した。
エラーはちょっとしたことで出たり、その都度原因が違う事もあるのですが、本記事ではピンポイントで出たエラーの事を書いています。
突然出たエラーの原因は、直前に何かを変えたりしたことを忘れてファイルを閉じてしまったからではありませんか？
最近どこか、変更しませんでしたか？
そうではなくて、もしも、今ファイルの作成中だった場合は、単純にデータ型や抽出条件が違う時に出るエラーだと覚えておいてください。
専門性はありません、ただの事例ですが、探してもネットの上位にはなかったので書きます。
なるべくエラーは修正したいですが、さっさとクエリやレポートを作り直した方が早い時もありますから、同じ事例の人がいたら、作り直すことも視野に入れて読んでください。
型が一致しないエラー、本来の意味 と今回の原因
「access」で、式や抽出条件の「型が一致しません」という内容のエラーは、通常、クエリで結合しようとしたフィールドのデータ型が一致していない可能性がある時に出る警告です。
クエリで結合させたフィールド同士のデータ型が、一方は数値なのに、一方はテキスト型の場合等が多いです。
その他には、nullだと思ったところが空の文字列だったりという事でも出たりします。
しかし、そうじゃない時に出る場合もあります。
今回は、私が元テーブルのフィールド名を変えたことが原因でした。
クエリが突然動かなくなった時は、テーブルで最近どこか変えたところがないか思い出してみて下さい。
ユニオンクエリでは、フィールド名の変更が反映されない
通常accessでは、テーブルのフィールド名を変更しても、クエリ側のフィールド名も自動的に変更され、エラーも出ずにそのまま使えることが多いです。
仮にエラーが出たとしても、パラメーター表示が出た後クエリデザインは開くはず。
クエリデザインを確認すると、名前を変えたフィールド部分が「式１：（旧フィールド名）」に変わっているので、クエリデザインから「式１：（旧フィールド名）」の部分を削除して、新しいフィールドを入れてやれば大体直ります。
レポートやフォームにしても、せいぜい、テキストボックスのデータソースを直す程度で済みます。
でも、ユニオンクエリを使用していた場合、フィールド名は更新されず、そのまま残ってしまいます。
なので、クエリを確認し、フィールドを修正していかないとなりません。
今回の原因で考えられることと、対処した方法
このファイルは、もともと、すごく長いテーブルを選択 クエリで6個に分けて、その後ユニオンクエリで結合させて、データを一列にしたものを参照や抽出用に使用していました。
ある日、テーブルのフィールド名を変更したことを忘れて、フォームに抽出条件を入れてマクロボタンを押した瞬間に「式で型が一致しません」という、意味不明なエラーが出たのです。
修正を試みた私は、マクロを入れたボタンが原因だろうと、 ボタンのマクロを確認しました。
まずは、ボタンに入れているマクロの条件等を確認。
しかし、ボタンに入れているマクロは「フォームを開く」のみで、それらしいものは見つからず。
次に、マクロが参照しているクエリの検証。
一つ一つ潰確認してみたら、ユニオンクエリでフィールドのパラメーター表示が出るようになっていました。
不明なパラメーター表示が出る時は、そこにはないフィールドを参照しようとしている時です。
・・・、おかしい・・・。
そんなはずはないのにな・・。
でも、確認してみたら、ユニオンクエリから作っているクエリは全てデザインが開かず、SQLしか見る事ができなくなっていました。
・・・、SQLとか・・。
苦手なんだよな・・・、これ・・。
ユニオンクエリがエラー元だとわかれば、該当クエリのSQLのフィールドを修正すればいいのですが、これが、一筋縄ではいかない。
ただユニオンクエリのSQLでフィールド名を修正しただけでは、エラーは直らないのです。
下手したら、accessのファイル自体が開けなくなることもありますので、ここをいじっているときは、なるべくファイルを閉じないように気をつけて下さい。
万が一、開かなくなった場合は、あわてずログアウトなり再起動なりをして、再度挑戦すれば開く事ができます・・（多分。なぜかは分らない。）。
ＳＱＬを修正する時は、半角や全角、スペルミスに気を付けて、該当箇所をすべて修正します。
もしかしたら、始めから書き直す方が早いかもしれません。
同様に、該当するクエリも全て修正
ユニオンクエリでフィールド名を直しても、まだエラーは続きます。
一旦ここでユニオンクエリの作業は終了します。
次は、デザインが表示されなくなった別のクエリのSQLを修正です。
ＳＱＬを見慣れていないとビビりますが、落ち着いてみてみれば、修正しなければならないフィールドを見つけることは難しくないので、頑張りましょう。
ファイル左側のナビゲーションウィンドウを開けて、全てのクエリを確認します。
エラーが出ているクエリだけではなくて、全てのクエリを点検しないとエラーが出続けます。
フィールド名が自動で更新されているクエリもあれば、変更前のフィールドが残っているクエリもあります。
一つずつ確認していくと、エラーの出ていない思いがけない所でフィールド名が変わっていなかったりします、これがエラーを引き起こしているのです。
フィールドを修正する時は、上書きせずに、一度フィールドを削除してから入れてあげたほうが、上手くいくと思います。
そして、この辺りを全部潰していかないと、いつまでたってもユニオンクエリでエラーが出ます。
何故かはわかりません。
ＳＱＬがどうしても苦手でうまくいかない時は、思い切ってデザインでクエリを作り直しましょう。
正直、そちらの方が早いです。
エラーの修正箇所を探すのは、時間の無駄です。
作り直した方が早いです。
レポートでパラメーターが出たり、昇順が反映されない場合
クエリが修正されて、データシートやデザインが表示されるようになったら一安心です
が、このクエリを基にしたレポートがある場合、レポートを開いてみましょう。
多分まだパラメーターやエラーが出ると思います。
まずは、変更箇所のフィールドのデータソースを直しましょう。
レポートをデザインビューで開いたら、プロパティをあけて、正しいフィールドを選択します。
レポートを確認しても、一見テキストボックスのデータソースが間違っていないように見えることがあります。
でも、プロパティを確認すると、実はデータソースに参照しているフィールド名が間違ったままのことがあります。
修正したフィールド名をデータソースにしている個所は、くまなく点検してみましょう。
これで大体直ります。
でも、クエリ側で指示した昇順が崩れていたり、レポートを開くときに、削除して既に存在しないはずのフィールドが、亡霊の様にパラメーターとして出没し、警告される時があります。
クエリを開くと昇順になっているのに、レポートだと反映されなくなってしまった場合 、多分もう直らないので、同じレポートをさっさと作り直しましょう。
これも、もう頑張って修正を試みるより作り直した方が早いからです。
エンジニアなら直せるかも知れませんが、多分エンジニアでも「新しく作った方が早いからそうする。」と言うと思います。
この辺りでユニオンクエリを確認すると、きっとデータが直っているはず。
エラーが出たり、クエリが壊れると一瞬頭が真っ白になりますが、accessは、テーブルとデータさえ残っていればほとんど再現可能ですから、壊れてショックを受けても、気を取り直してクエリから組みなおしてみて下さい。
いざとなれば、マクロがなくても何とかなります、不便だけど。
今日の記事は、ピンポイントでニッチなエラー対処事例なので、心当たりのない方は参考にならないかもしれません。
また、accessを一から始める方には全く意味が通じない記事ですが、こんな記事があったなと覚えておいていただければ幸いです。
読んでいただき、ありがとうございました。
