文字通り何百もの Access データベースがネットワーク上に浮かんでいます。使用量が少ないもの、使用量がかなり多いもの、まったく使用していないものがあります。私たちがやりたいことは、これらのデータベースを管理されたデータベースに集中させ、その中のレポートとフォームを可能な限り保持することです。
これを行う利点は、ある種の使用状況の追跡ができることと、これらのアプリに保存されている重要な分散データのいくつかにより注意を払うことができることです。
RDBMS (Oracle、MS SQL サーバー) やそれが実行されるスタック (LAMP、ASP.net、Java) には実際の制約はなく、明らかにこれに対する特効薬はありません。自動化された方法で最初の煩わしい作業を削除できるものが必要です。
(アップサイズ ウィザードを使用するか手動で) ユーザーを SQL サーバーにアップサイズします。通常はかなり簡単です。すべてのアクセス テーブルを SQL サーバーへのリンク テーブルに置き換え、すべてのフォーム/レポート/マクロをアクセス状態に保ちます。アクセスへの投資が失われることはなく、ユーザーは通常どおりビジネスを続けることができます。SQL Server と集中バックアップの信頼性が得られます。覚えておいてください - これは、数百ではなく、いくつかの大規模なアクセス データベースに対して行われました。私は数十のパイロットを行い、それがどのように機能するかを確認します.
更新: SQL サーバーの移行アシスタントであるこれを見つけました。一見の価値があるかもしれません: http://www.microsoft.com/sql/solutions/migration/default.mspx
更新: はい、設計が不十分なデータベースにはリファクタリングが必要です。アクセスのスプロール化をどのように処理するかについては? 多くの技術ユーザーがいる企業でこれに遭遇しました（特にエンジニアはこれに最悪です...そしてExcelのスプロール）。監査を行いました - (バックアップ後) 1 年以上触れられていないデータベースを削除しました。「所有者」は、データベース内の場所および/またはデータに基づいて割り当てられました。データベースが「S:\quality\test_dept」にある場合は、品質管理者と主任テスト エンジニアがその所有権を取得する必要がありました。そうしないと、データベースを削除する必要がありました (バックアップ後に再び)。
Access アプリケーションのサイズを大きくすることは特効薬ではありません。より高速になるものもあるかもしれませんが、一部の種類の操作は実際の犬になります。つまり、アップサイズされたアプリを徹底的にテストし、パフォーマンスのボトルネックに対処する必要があります。通常は、データ取得ロジックをサーバー側 (ビュー、ストアド プロシージャ、パススルー クエリ) に移動します。
ただし、それは実際には質問に対する答えではありません。
問題に対する自動化された回答はないと思います。実際、これは人間の問題であり、プログラミングの問題ではないと思います。誰かがネットワークを調査し、すべての Access データベースの所有者を特定し、ユーザーにインタビューして、何が使用されていて何が使用されていないかを調べる必要があります。次に、各アプリをエンタープライズ全体のデータ ストア/アプリに折りたたむ必要があるかどうか、または少数のユーザー向けの小さなアプリとして最初に実装する方が適切なアプローチであったかどうかを評価する必要があります。
それはあなたが聞きたい答えではありませんが、プログラミング作業ではなく人/管理の問題であるため、正しい答えです。
Oracle には、MS Access システムを Oracle Application Express に移植するための移行ワークベンチがあり、調査する価値があります。
それで？サーバーをAccessデータベース専用にします。
これで、ある種の使用状況追跡の利点が得られ、これらのアプリに保存されている重要な分散データのいくつかにさらに注意を払うことができます。
これはとにかくやろうとしていたことであり、NTFSの代わりに別のデータベースエンジンを使用したかっただけです。
そして今、あなたはユーザーをあなたのサーバーに強制しなければなりません。
さて、あなたは彼らにあなたがもう古いバックアップで彼らのデータを上書きするつもりはないことを彼らに伝えることによって彼らを励ますことができます、なぜなら今あなたはデータを所有し、あなたはもうそれをしないからです。
また、アクセス中のウイルススキャンからフォルダを除外するため、アプリケーションの実行速度が向上することを伝えることができます（他のデータベースに対しては除外しないため、SQLインジェクションでいっぱいです。マルウェアですが、これらのデータベースはインターネットに公開されません）、パケット署名をオフにすることを計画しています（専用サーバーでは必要ありません：ファイル共有をドメインサーバーに置く人のみです） 。
簡単なアップグレードパス、ユーザーへのサービスの向上、ITの集中化と制御の向上。誰もが勝者です。
David Fentonのコメントに加えて
管理ルールは次のようになります。
データベース内のデータが 1 人のユーザーによって (単独で) 自分の作業のために使用されている場合、そのデータを自分のネットワーク共有に保持できます。
データベース内のデータが複数の人によって使用される場合 (2 人だけであっても)、そのデータベースは中央サーバーに置かれ、IT の管理下に置かれる必要があります (バックアップ、スキーマの変更、インターフェイスなど)。 ）。これは、経験豊富な誰かがショー全体を調整する必要があるためです。そうしないと、次の担当者の時間/リソースを危険にさらすことになります.