Access2000からＡｃｃｅｓｓ2003・2007など、上位製品へのバージョンアップについて。

質問

会社でアクセス2000を使用して業務アプリを作ることになりました。（費用の面で、現段階で2002や2007を購入することは出来ません。）
しかし、将来的には作成したアプリを2002か2007Ver.へ移行させる予定はあります。

＜そこで、ご質問いたします。＞
明らかに将来、上位Ver.へ移行すると決まっている場合、開発はなるべくマクロ中心に作成し、ＶＢＡの使用は最小限に抑えるべきなのでしょうか？
小耳に挟んだ話だと、アクセスでの上位Ver.への移行は、マイクロソフトが、マクロだと変換ツールを組み込んでいるので、新機能以外はほぼエラーもなく、たいした修正もしないで置き換えられると聞きました。逆に、ＶＢＡ中心で作成していると、うまく変換されないことが多々あり、かなり修正に手間取るとお聞きしました。

(1)この情報は、正しいのでしょうか？もし、正しいのならそれはなぜなのでしょうか？（マクロもＶＢＡの一種ではないのですか？）

(2)今後も、アクセスはバージョンアップするでしょうし、その際の修正の手間が最小限にしたいのなら、変換機機能を最大限に使用できる、マクロ中心に作成しておいたほうが、無難なのでしょうか？

開発は初心者なので、この様な初歩的な質問で申し訳ありませんが、ぜひ、プロの方のご意見をお聞かせください。

回答No.1

FEX2053 · ベストアンサー

>(1)この情報は、正しいのでしょうか？

正しいです。Accessは97/2000/2002の間で細かい変更がしばしばあり、
VBAのコードがそのままでは使えない場合が結構あります。おまけに
「動かない」事実が動かしてみて始めて分かる（それも特殊な条件下
だけとか言う場合が少なくない）ことも多く、移行には必ずシステム
テストが必要になります。

2007-VBAはまだ使ったことがありませんが、同じような問題は発生して
いるもとの思いますよ。

>(2)変換機機能を最大限に使用できる、マクロ中心に作成しておいたほうが無難

マクロはマクロの状態で存在し、実行する時に逐次VBAのコードに変換
されます（インタプリタとして処理されます）。ですので、同じマクロ
でも変換されるコードはAccessのバージョンごとに異なるのです。

マクロのコードはAccess間で互換性がありますが、困ったことにマクロでは
実現できない処理が山ほどあります。逆に言えば、マクロだけで実現できる
処理しかしない・・・というなら、マクロで作ったほうが安心です。

回答No.4

gatt_mk

正直言って作り方次第だと思います。

私は基本的にACCESS2000で作っており、ほとんどの処理はVBAでやっています。しかし、データアクセスに関してはADOを使わずにDAOでやっています。基本的にVBAでの参照設定でDAO3.6が参照できるようにしておけば、どのバージョンでも一応問題なく動いています（2007はまだ使っていません）。
どのバージョン（2002，2003）でも基本的にACCESS2000形式として動いています。

ACCESS2000以降は、基本的にはデータアクセスはADOが標準になっていますので、バージョンによってADOの最新ライブラリのバージョンが変わってしまい、ADOを使って処理を作っているとそのせいで問題が発生するかもしれません。私の作っているものはDBとしては主にローカルのJetしか使わないので、DAOの使用で特に困っていません。DAOのライブラリは3.6以降のものは出ていないので、そのせいでACCESSバージョンによる問題は起きていないのではとも思います。

ただExcelへのデータ渡しでExcelのライブラリを使ったりすると、インストールされているExcelのライブラリのバージョンが変わってしまうので、一端上位ACCESS下でで動かしたものを、下位のACCESSの環境下にもってくるとExcelライブラリの参照ができないというエラーが出たりもしますが、下位のバージョンで使っているものを上位で使う限りは、特に問題は起きていません。

いずれにしても作り方次第ではないでしょうか。そうしたトラブルをいろいろ経験することで、どこに気をつけたらいいかもわかってくると思います。

回答No.3

noname#140971

一介のデザイナーですので参考までに・・・。

Access2.0→Access97→Access2000→Access2002

とバージョンアップを図ってきました。
この過程で、

・マクロは良く判らないので最初から使っていません。
・クエリも今一つ信頼していないので使っていません。
・もっぱら、関数群の充実に腐心してきました。

バージョンアップでは、関数の動作をチェックする作業が殆どです。
関数のコードは、その時々で最適化していきます。
が、プログラムコード自体は基本的にいじりません。
こういう仕掛けが宜しいと思います。

＜蛇足＞

Access2000 で業務アプリケーションの開発に今から着手。
ならば、MSDE+Access でクライアント・サーバーシステムがお勧めです。

回答No.2

a3453a

変換に苦労したといえば
ACCESS97　から　ACCESS2000　へ
移行した時に大いに苦労しました
いろいろと変更させられてしまいましたが
大きい点はデーターベースドライバー（エンジン）が
大きく変ってしまった点でした
ＤＡＯ方式とかＡＤＯ方式というやつですね
ここを変更されてしまったので
（マイクロソウトからすれば機能追加・強化ですが）
ＶＢＡのデーターベース定義文のところで
少々苦労させられました
あと気づいた点とすれば、クェリーでややこしい
ことをしていると、新バージョンでは通用しない
といったことも体験しました
----------------------------------------------
結論ですが、
マイクロソフトの場合は新バージョンでは
ほとんど旧バージョンの救済措置をとっていますので
（むろん、無視されてしまうロジックもありますが）
マクロだろうがＶＢＡだろうが、リスクは変らないと
思います
たしかにACCESS2000などでも旧様式の変換という
機能を使うと一部エラーになってしまうことは
たくさんありますが、ＶＢＡ部分だけに起きる
ということでもありません

まぁ、マクロでできることはマクロで
マクロでできないことだけはＶＢＡで。。。。。
というスタンスが正解なのではないでしょうか