現在WIN7のPCでAccess2003を使っています。それをWIN10のPCでAccess2010に変更しようと思いWIN10のPCでAccess2003をaccdb形式で保存して動作させてみました。データは問題ないのですが、心配してた通りフォームのボタンに記述しているVBコードが全く動作しませんでした。例えばフォームを開くも駄目でした。1つづつボタンをやり直すしかないものでしょうか? 膨大にコードがありどうしたものかなと思っております。何かいい方法があれば・・・
通報 ...
特別なことをしてなければたいてい上位互換性はあります。
とりあえず、参照設定に参照不可の項目がないか確認してみてください。
定番のVBA関数でコンパイルエラーが出たときの対処法:Excel VBA|即効テクニック|Excel VBAを学ぶならmoug
回答すぐ頂いたのにこちらの確認が遅れてしまってすみませんでした。またACCESSは2010でなく2019でした(タイプミスしてまして失礼しました)。確認したところ参照設定に不可項目はありませんでした。設定は規定のままでしております。マクロの命令は動作しているのですがVBコードでの分が動作していませんでした。プログラム全然知識ないのですがバージョンの違いでしょうか?
たぶん、お節介ですが、すみません、もう少し情報が要求されると思いまして。
2003mdb形式→accdb形式でしょうか?それは、WIN7でも期待どおりに動かないの?
VBAコードが全行動かないの?一部動かないの?例えば、どんなVBAコードが動かないの?
Accessファイルをサーバーに置いて、ローカルからリンクテーブル経由で繋いでいる?
りんごさんへ
コメントありがとうございます。
WIN10PCの方で2003mdb形式→accdb形式に変換して様子を見ています。WIN7PCの2003mdb形式の方はずっと使っており問題ありませんでした。それをWIN10PCに元のファイルをコピーしてaccdbで保存したのです。フォームも沢山あるのですが例えばメインパネルフォーム上ボタンのVBAコードの Docmd.OpenForm”***" 等も動作しないのです。Accessファイルはサーバー経由ではなく使用するPCにあります。Access2019は2003と大きく表示構成が変わっていてちょっと戸惑っています。
もしかして
[イベントプロシージャ]
(半角)になってるとかそのaccdbファイルで、新規にフォームを作成して、コマンドボタンを配置して、下記のような簡単なコードを記述した場合は動作しますか。
回答ありがとうございます。新規フォーム作成してコマンドボタンにMsgBox***を記述しますと動作しました。元のファイルのフォームに新たにボタンを追加して記述しても動作はしませんでした。そのファイルにはコードでなくマクロでのコマンドボタンもあるのですが、それは動作します。
VBAが動作しないのは、もともとあったフォームすべてですか。それとも特定のフォームのみですか。
また、動作しないとは、コマンドボタンをクリックしてもなんの反応もないという状態でしょうか。それともエラーが出て動作しないのでしょうか。
回答ありがとうございます。
全てのフォーム上のvba コードでしているコマンドが効いていません。エラーがでるのではなく反応していないのです。先程MsgBoxを試したのは新しいファイル作成してそれで確認しました。
新規に空のaccdbファイルを作成して、そこでフォームを作成してコマンドボタンを配置して確認したということでしょうか。
もし、そうなら、Access2003から変換したaccdbで、新規フォームを作成してそこにコマンドボタンを配置した場合は動作しますか。
回答ありがとうございます。
Access2003から変換したaccdbで、新規フォームを作成してそこにコマンドボタンを配置してMsgBoxで試したところ無反応でした。変換したファイルに問題あるのでしょうか?
マクロが動いているそうなので、関係ないとは思いますが、念のため、コンテンツの有効化は出来ていますか?
まずは、りんごさんの指摘されている点について確認してみてください。
それで解決しない場合は下記の手順を試してみてください。
新規に空のAccdbファイルを作成する。
このファイルに、VBAの動かない問題のAccdbファイルから、すべてのオブジェクト(テーブル、クエリ、フォーム、レポート、モジュール)をインポートする。
この新しいAccdbファイルで動くかどうか確認してみてください。
確認が大変遅れてしまって申し分けありませんでした。
まずコンテンツの有効化は出来ていませんでしたのでメッセージバーにてONして試すとコンパイルエラーが多発したので(この時は理由が分からず)、次に空のデータベースに全てインポートして試しました。やはりコンパイルエラーが出ました。そこでコードの記述に問題あることに気づきました。Private Sub ○○/△△_Click()の様にスラッシュや()の文字を多用していたからです。それでプロシージャの区分線が消えているところが多数ありました。
恥ずかしながらプログラムの知識がないのに見よう見まねでコードを記述していたのですが、こういった文字は使うべきではないのですよね?
全てを試してはいませんが不思議なのはそういう文字を使っていないコードで無反応なボタンがある様なので一旦コードを削除して再度同じコードを記述すると動作しました。これもどこかのコードの記述にまずいところがあるからなのでしょうか?
例えばボタンのクリック時に[イベント プロシージャ]を指定して[...]をクリックすると自動でコードが作られますが、この時のプロシージャ名が「ボタンの名前_Click」のようになります。
フォーム上のコントロールの名前は開発者が分かりやすいようにつけましょう。と当たり前のことがあるんですが、このとき「請求書表示(消費税込み)」のようなボタンだったりすると件の問題が発生します。ただ、この名前自体に不具合はなく、ここからVBAのコードを記述する場合には不具合が起きますが、マクロを割り当てる場合には問題が起きません。厄介な問題と言えるでしょう
また、これら記号(や、半角カタカナ)の問題はOS(Windows)の問題とも関係していて、昔は全角の記号であれば問題なかったという歴史があります。(バッドノウハウですが)
「こういった文字」は使うべきではないんですが「こういった文字」自体が歴史の中で変化してしまっているということですね
ACCESSのバージョンアップ問題の中ではよくある方の問題だと思います
実行しようとしているコードに不具合が見当たらないのに・・・というのも「よくある」ことです。
VBEのメニューから「デバッグ」→「VBAProjectのコンパイル」を実行してエラーがある場合はどんな問題が発生してもおかしくないと考えましょう
区切りがついたら、新しい質問を、具体的なコード付きで、立てるといいかも。
色々と回答頂きありがとうございます。大変参考になります。分かり易い様に付けた名前がよくなかったのですね。以後注意していきます。一つづつ時間かけて修正する様にします。その中で解決出来ないことは、りんごさんからの提案通り次は具体的なコード付きで新たに質問する様に致します。今回一から作り直しにならなかっただけ幸いでした。
お手数かけました。