コア在庫の倉庫保管および請求システムに使用する12年前のMsAccessアプリがあります。すでにSQLServerバックエンドで実行されていますが、すべての「ロジック」、フォーム、およびレポートはAccessにあります。在庫トランザクションを非一時的なものから一時的なものに変えるために必要な大量のメンテナンススラッジを経験した後、私はいつかこれをコードに変換して、はるかに保守可能でテスト可能な環境でロジックをより適切に管理できるようにする必要があることに気付きました。
管理しやすく効率的な方法で.Netアプリケーションに変換できるようにするためのテクニックは何ですか？
1つのアイデアは、クエリをストアドプロシージャに変換してから、アプリをAdpプロジェクトに変換することでしたが、フォームとレポートの処理方法についてはまだわかりません。
また、それが重要な場合、私は私の会社の唯一の開発者です。
簡単な答え: 移行は簡単に自動化できるものではないようです。
私の推測では、システムを一度に 1 つずつ書き直す (そしてインストールする) のが最善の策であると思います。たとえ (おそらく) ユーザーが古いバージョンと新しいバージョンをしばらく並べて実行し、異なるビットを使用することを余儀なくされたとしてもです。機能の。どの機能をどの順序で移行するかを慎重に検討することで、その手間を最小限に抑えることができます。
たとえば、1 日中 1 つの画面だけを使用する必要がある職務を持つ 1 人のユーザーがいるとします。最初にその画面を付随する機能とともに移行すると、そのユーザーはすぐに新しいシステムに移行し、古いシステムを残すことができるため、メンテナンスの負荷が軽減されます。
したがって、これらはあまり多くの情報に基づいていないアイデアにすぎません。とにかくこれが役立つことを願っています。
すでにいくつかのビジネスロジックを備えたasp.netがあるので、これを開いてWebサービス（asmxファイル）としてアクセスできます。アクセスのバージョン（xp / 2003など）用のMicrosoft Office Web Services Toolkit用のGoogle。これにより、Webサービスを呼び出すためのvbaプロキシクラスが作成されます。コード（コントロールの読み取りと書き込みを行うvba）を介してWebサービスデータをフォームにバインドするか、Webサービスからのデータを使用してローカル一時テーブルを作成し、通常のアクセスバインドを使用できます。
何に最も慣れているか（code / tsql）に応じて、ロジックをストアドプロシージャ、ビジネスロジックレイヤー、またはハイブリッド（両方）に配置できます。ストアドプロシージャよりもコードをテストする方が簡単で、ビジネスロジックのSQLサーバーにバインドされないようにします。つまり、データベースを変更したり、データベースなしでコンポーネントをオフラインで開発/テストしたりする場合です。LINQなどの新しい.net機能は非常に優れたパフォーマンスを発揮するため、データベースアクティビティのストアドプロシージャに依存する必要はありません。
Webサービスへのすべてのビジネスロジック/データアクセスをリファクタリングするまで、アクセスフロントエンドユーザーインターフェイスを保持します。次に、必要に応じて、Webサービスを使用するasp.netアプリまたはwinformアプリを作成できます。（これは急な学習曲線であり、アクセスデータシートビューと比較できるデータグリッドがまだないため、当面はuiとしてwpfを避けてください。）
レポート
アクセスレポートは、SQLサーバーレポートサービスにアップサイズできます（レポートのvbaはアップサイズされないため、ストアドプロシージャにtsqlを記述することをお勧めします）。完全なSQLServer製品がない場合でも、reportviewerコントロールを使用して、asp.net（または標準バージョン以上のVisualのwinform）にレポート（ http://www.gotreportviewer.com/を参照）を書き込むことができます。 Studio）ado.netデータセットへのバインド。
その他のオプション： .net dllを記述し、com相互運用機能を使用できます。このアプローチにより、機能の記述を徐々に開始できます。.net ui（winformなど）は使用しないでください。accessuiではうまく機能しません。ビジネスロジックまたはデータアクセスロジックを記述して、vbaからこれらのクラスを呼び出すことができます。その後、必要に応じて、このコードをasp.netまたはWebサービスに移動できます。
除外するもの：
サイドバイサイドバージョンで新しいアプリを作成するアプローチは好きではありません。単一の開発者として、あなたは心配するのに十分です。おそらく、両方のバージョンで機能を追加し、1つではなく2つのバージョンをデバッグすることになります。
vb6フォームの相互運用機能はアクセスには機能しません。
述べたようにADPはかなり死んでいます。（パフォーマンスを最適化するためにローカルテーブルを頻繁に使用し、コードを介してのみ呼び出すことができ、リンクされていないため、これらは好きではありませんでした）
You may be able to convert your vba modules and class modules to vb.net using The Visual Basic Upgrade Wizard (in visual studio) but it doesn't upsize everything (e.g. dao/ado code to ado.net code) and doesn't create code that is optimized for .net and may not be easy to write unit tests on depending on the design of the vba code. I recommend rewriting the code (try Test Driven Development if you are serious about testing to see if you like it).
InteropFormsToolkitを検討することを検討します。私が理解しているように、このツールを使用すると、VB6内から.NETフォームを非常に簡単に使用できるので、MicrosoftAccess内からも使用できるのではないでしょうか。その場合は、アプリケーションを段階的に.NETに移行するのに役立つ場合があります。クイック検索を行ったところ、Microsoft Accessでの使用に関するガイドが見つからなかったため、これが盲目的な路地であることが判明した場合はお詫び申し上げます。
adpに変換することは、長期的には良い解決策にはなりません。このテクノロジーはMicrosoftによって放棄されています。
.netに切り替えたい場合（なぜ？.netを好む理由がありますか？）、読み始めて、簡単なアプリを作成してから、このデータベースをアプリケーションに変換するタスクを開始することをお勧めします。
だが...
あなたと会社は、このプロジェクトに伴うリスクについて考える必要があると思います。経営陣がまだ存在していないレポートを必要としている週に、病気になった場合はどうなりますか？地元の小さなソフトウェア開発会社を探すことをお勧めします。彼らは喜んでお手伝いします。たぶん、あなたはあなたが「リード開発者」であり続け、バックアップのためだけにそれらを使うように手配することができます。