現状、言語はVBA、DBはAccessというシステムがあります。
言語をVB6.0、DBをWinSQLServerに移行する場合、VBAのソースはVB6.0上でどの程度流用可能でしょうか？
また、VB.NETにする場合、ソースの流用はどの程度可能でしょうか？
一般的な意見です。
一言に「流用」といっても限界があるでしょう。
バッサリと切り捨てた言い方をするのは、なんなんで少し。
何をシステムの中でされているのか判り兼ねますが、簡単な処理ルーチン等が
あるならば結構そのまま流用できそうです。
問題なのはVBA(これって多分Accessの中に記述してるんですよね？)で、
DB接続関係はまるっきり書き換える必要がありそうです。
ソースの構造次第ですが、ちゃんと既存のコードが綺麗なクラスとして
細分化されていたり処理ルーチンも小分けされているのなら、
それこそ「流用」は可能でしょうし、むしろ実績がある点から考えて
使用することをお勧めしますが、お世辞にも綺麗な構造で無い場合
へたに流用するとわけがわからなくなりますよ。
.NETに関してはコードの見た目は似てますが、考え方等がまるっきり
違ったりします。コードに関してもVB特有関数をバリバリ使用していて
「Imports Microsoft.VisualBasic」など宣言して
VB依存型の記述をするよりは、.NETのメソッド記述の転換して行った方が
今後のためによろしいのではないでしょうか？(大きなお世話ですみません。)
最後に質問の回答としてですが、
「流用はものによっては出来なくないが、新規の作成とあまり手間が変わらない」
ですかね^^；
Access 2000以降では、直接、SQL Serverを扱えますよね。
# Jetデータベースの時は、mdbファイルにフォームが格納されますが、
# SQL Serverを相手にする時は、adpファイルのプロジェクトとして
# 作成されていたと思います。
Access 2000/2002/2003のヘルプには、JetとSQL Server/MSDEの
違いなども解説されていたと記憶しているので、DB自体の機能差に
関しては、今回は説明を省きます。
さて、mdbの場合は、DBとの接続に「DAO」という技術が使われており、
adpの場合は、「ADO」という技術が使われていたわけですが、これらの
技術(ADO/DAO)は、いずれもVB6でも引き続き使用可能となっています。
しかも、VBとVBAは、言語仕様はまったく一緒です。
つまり、VBAでRecordsetを開いて、AddNew/Delete/Updateするような
部分などは、ほとんどロジックの変更無しで移行する事ができます。
とはいえ、言語仕様以外の部分(Access自体が持つ機能)に関しては、
コードの書き直しが必要となってくるでしょう。例えば、Accessにしか
無いイベントや、逆に、VB6にしか無いイベントなどがあったりしますので。
厄介なのは、この「Access自体が持つ機能」の部分の移行作業です。
いくつか例を挙げてみると……
・DoCmd.TransferXXXX などの、DoCmd系メソッドは使用不可。SysCmd系も同様。
・AccessのフォームをVB6のフォームに変換するツールは提供されていない。
・VB6のComboBoxは、複数列の表示機能などが無い。
・VB6のフォームは、スクロールバー自動表示機能が無い。
・VB6には、サブフォームの概念が無い。
これ以外だと、印刷ツールの違いもあります。
VB6で印刷に使われる手段としては、以下のような物があります。
・Printerオブジェクト……Lineメソッド、Circleメソッド、Printメソッド
などを使って出力する。AccessのReport.Line、Report.Circle等と同様。
・CrystalReport……市販の帳票コンポーネント。VB6には機能限定版が付属。
VB6のインストーラではインストールされない(CD-ROMから別途インストール)
・DataReport……VB6付属の帳票コンポーネント。グループ化機能が弱いなど、
今ひとつ使い難いので、私個人的としては、あまりお奨めしません。
・外部ツールを使用……AccessやExcelをVBからプログラム制御するとか、
市販の印刷ツール(ActiveReportとかVisualFormadeとか)を使うとか。
ファリンファリンさん、魔界の仮面弁士さん、ありがとうございます。
もう少し、既存システムの内容を詳しく書きます。
現在、Access97で構築したシステムを導入しています。そのため、Accessのバージョンupをするよりは、そういったものに出来る限り左右されないシステムを構築したいと思いVB or VB.NETを考えました。また、DB構造を見直し、レスポンスを考慮しWinSQLServerを考えました。
既存システムのアプリ構造はいたってシンプルです。
基本的には、データの書き込み、照会がほとんどです。複雑なチェック処理等はほとんど存在しません。
総データ数としては、約30,000件ぐらいです。
いかがなものでしょうか？