1

私は現在、レガシー MS Access アプリケーションの開発と保守を担当する 4 人のチームに所属しています。

アプリケーションは非常に大きく、何百ものフォーム、レポート、クエリ、およびテーブルがあります。

現在、フロント エンドは約 7 つの mde コンポーネントに分割されています。それぞれのコンポーネントは、基本的にはそれ自体がアプリケーションであり、基本的には単なるメニュー GUI である共通のフロント エンドによって結合されています。

リンク テーブルを使用して、コード自体で OpenDatabase(C:\access.mdb) 呼び出しを使用して、このフロント エンドを MS Access バック エンドに接続します。このアプリケーションはしばらく前から存在していたため、DAO を使用して Access 97 バックエンドに接続しています。

これは、アプリケーションのすべてのユーザーが、変更を行うためのデータベースの独自のローカル コピーを持っていることを意味します。一度に 1 人だけがデータを操作できるように、慎重に変更管理された環境を用意しています。マスター データベースを次の人に渡す前に、すべての変更を検証する必要があります。

この変更管理環境は控えめに言っても息苦しいものであり、1 人のユーザーによるアクセスが実行不可能になる時間枠内で、より多くのデータ変更を行う必要がすぐに出てきます。

したがって、マルチユーザー アクセスに移行する必要がありますが、マルチユーザーとは約 4 人だけを意味します。この人たちはおそらく同じオフィスに物理的に配置されていないため、何らかの形のリモート db 接続が必要です。

1 年か 2 年のうちにアプリケーション全体が作り直され、フロントエンドとバックエンドの両方が MS Access から離れる可能性があります。ただし、できるだけ早くマルチユーザー アクセスが必要です。

では、至福のマルチユーザーへの最短の道は何でしょうか?

検討中の提案には次のものが含まれます。

  • MS Access が通常のネットワーク ドライブにアクセスしていると認識するように VPN を設定します。これは遅くなるようで、VPN の信頼性が十分かどうかはわかりませんが、いずれにせよ、これは一時的な解決策にすぎません。
  • mdb バックエンドを、SQL Server などのマルチユーザー リモート使用を目的としたものに変換します。これを迅速かつ簡単に行う方法がわからないだけです (たとえば、フィールド検証ルールに依存しています)。また、他のアプリケーションが同じ .mdb ファイルをデータ入力として受け入れるため、MS Access 形式に戻す必要があると思われます。
  • 1人か2人で数ヶ月でできることなら何でも。

編集: 以下のコメントに応答します。

アプリケーションによって処理されるデータは、安全性が非常に重要なデータです。めったに変更されず、エクスポートする前に論理エラーがないことを示すために検証する必要があります。実際には、データはアプリケーション自体よりも厳しい制限を受けています。

データは重要な方法で相互に関連しています。そのため、複雑なビジネス ロジックが原因で、あるテーブルのレコードを変更すると、別のテーブルのレコードが無効になる場合があります。そのため、現時点では、mdb データ ファイルの 1 つのコピーがマスター データベースとして指定されています。一度にマスターを持つのは 1 人だけです。それを変更したい場合は、現在それを持っている人からそのデータベースを取得する必要があります。データが変更されることはめったになく、これが発生するのに十分な時間があるため、これは通常問題になりません。

しかし、大きな変化が迫っていますが、この方法で作業するのに十分な時間が与えられていません。一度に複数の人がデータに取り組む必要があります。ネットワーク ドライブで mdb ファイルを共有し、同じオフィスにいる複数の人がほとんどまたはまったくリスクなしにそのファイルで作業できることを認識していますが、データを同時に処理するには、さまざまな会社の人が必要です。 . 私が理解しているように、VPN を設定してデータを共有するのは悪い計画です。

バックエンドを MS Access から変更し、SQL サーバーのようなものに移行する必要があると思います。しかし、この方法でスキーマを変換するのはどれほど簡単でしょうか? MS Access テーブルの検証規則は SQL Server でどのように表されますか?

4

3 に答える 3

1

ボックスのアクセス権は原則としてマルチユーザーがファイル共有としてアクセスします。これが意味することは、バックエンド データベース (mdb ファイル) をサーバー上の共有フォルダーに置くことができるということです。これにより、オフィス内の数人が同時にアプリケーションを実行できるようになります。ただし、これは典型的なオフィス LAN について話していることを意味します。リモート接続、VPN、およびワイド エリア ネットワーク (WANS) について話し始めると、ファイル共有としてのアクセスの使用は安定しません。

したがって、典型的なオフィス ネットワーク環境で 3 ~ 4 人しかいない場合は、アプリケーションによっては、サーバー上の共有フォルダーにバックエンドを配置し、すべてのフロント エンドをそれぞれの共有フォルダーに展開し続けることができる可能性が非常に高くなります。それらは、共有フォルダー上のその 1 つのデータベース バックエンド (mdb) ファイルにリンクされています。MS アクセスは、この方法で非常にうまく機能します。

ただし、ある種の VPN または WAN について話す場合、考えられる解決策の 1 つは、バックエンドの mdb ファイルを SQL サーバーに移動し、現在のアプリケーションからすべてのフォーム、レポートなどを引き続き使用することです (アプリケーションのほとんどは実行されます)。これを行う前と同じように)。

考慮すべきもう 1 つの非常に優れたテクノロジは、シン クライアント、またはいわゆるターミナル サービスです。ターミナル サービスは、リモート デスクトップ システムの高級版にすぎません。TS を使用すると、帯域幅がかなり制限されていても、離れた場所からアプリケーションを実行して使用することができます。

ただし、典型的なオフィス LAN で 3 人から 4 人のユーザーについて話している場合、アプリケーションがそのまま実行される可能性は非常に高く、バックエンド データベース ファイルをどこかのサーバー上の共有フォルダーに移動するだけです。ただし、これが機能するのは、すべての人が同じ小さなオフィス LAN にいる場合のみであり、ある種のリモート接続や WAN/VPN では機能しないことを強調することはできません。そのため、WAN/VPN の場合は、ターミナル サービスを使用するか、バックエンドを SQL サーバーに移行することを検討し、アプリケーション フロントエンドをそのまま使用します。


編集 - 詳細情報: わかりました。ここに詳細情報があれば、先に進むことができます。前述のように、ms-access はすぐに使用できるマルチユーザーです。このデータを処理するには、さまざまな場所にいる人が必要です。したがって、これは、この異なる場所の問題に関係なく、アプリケーションをマルチユーザー機能用にセットアップする必要があることを意味します. マルチユーザー用にアプリケーションをセットアップしたら、さまざまな場所からソフトウェアを使用できるようにするという問題に取り組みます。

これは、会社のクリスマス パーティーを管理するための何かがある場合と同じです。クリスマス パーティーの後にファイル全体を削除して、来年のクリスマス パーティーに向けて最初からやり直すように設計した場合でも、このアプリケーションで複数の使用を許可することができます。ただし、デザイン上、同時に複数のクリスマス パーティーを開催することはできません。したがって、この場合、アプリケーションがマルチユーザーであるという事実ではありません。このタイプのシナリオでは、クリスマス パーティーの年表と呼ばれる新しいテーブルを実際に追加することがあります。次に、アプリケーション内のすべてのテーブルを子テーブルとしてこのマスター テーブルに関連付けることができます。そうすれば、このデザインで同時に複数のクリスマス パーティーを開催できます。次に、アプリケーションを起動すると、

したがって、上記の 2 つの別個の問題を混同しないでください。ターミナル サービスでアプリケーションをマルチ ユーザーにできるようにする方法を尋ねるのは意味がありません。そのようなことはありません。TS が行うことは、既にマルチ ユーザーになっているアプリケーションを使用して、離れた場所にいる人々がそのアプリケーションを使用できるようにすることです。したがって、TS は、人々がインターネット上のどこからでもアプリケーションを実行して使用できるようにするシステムです。ただし、アプリケーションが同時に複数のクリスマス パーティーを開催できるようにするかどうかは、デザインによって決まります。

したがって、MS Access をマルチユーザーにする必要はありません。MS Access は、すぐに使用できるマルチユーザーです。別の場所にいるユーザーがアプリケーションを使用できるようにするテクノロジを採用する以外は、何もする必要はありません。つまり、それが TS の機能であり、SQL サーバーができることでもあります。

設計で 1 つのプロジェクトしか許可されていない場合、世界中のさまざまな場所にいる複数のユーザーがアプリケーションを使用できるようにすることができますが、アプリケーションの設計上の制限により、アクティブなプロジェクトは 1 つしか許可されません。

したがって、テーブル更新ロジックなどはすべて以前と同じように機能します。アプリケーションでは、1 人のユーザーがアプリケーションを終了し、別のユーザーがアプリケーションに入って作業を行うことができるようになっていますか? オフィスにはスタンドアロンのコンピューターが 1 台しかないと仮定します。さまざまな従業員が 1 日のうちに座って、その 1 台のコンピューターと 1 つのアプリケーションを 1 つのバックエンドで、それぞれのプロジェクトに使用できますか?

そのため、SQL サーバーやターミナル サービスを使用しても、現在のようにアプリケーションのマルチ ユーザー数が増える (または減る) ことはありません。これらのテクノロジーにより、アプリケーションを同時に使用できるユーザーの数を確実に増やすことができます。

したがって、MS アクセスは現在マルチユーザーです。ただし、SQL サーバーまたは TS が行うことは、ユーザーがこのアプリケーションにリモートで接続する方法に関して、はるかに柔軟に対応できることです。

于 2009-06-30T14:40:55.667 に答える
0

IMO 他にどのようなソリューションを検討するかに関係なく、データベースをマルチユーザー サーバーに変換する必要があることは間違いありません。便利なアップサイジング ウィザードがあります ( http://support.microsoft.com/kb/237980 )。Access では許可され、SQL サーバーでは許可されない項目に遭遇する可能性がありますが、ほとんどの場合、問題はありません。この新しいデータ ソースを使用するようにローカル アクセス コピーを指定することができます (たとえば、ODBC を介して)。すべてほぼ同じように機能するはずです。何年もこれを行っていないので、これらのフィールド検証ルール (まだフォームに残っているのではないでしょうか?) がどうなるかわかりません。SQL サーバーの試用版をダウンロードし、これを 1 時間以内に実行して、どれだけの労力が必要かを感じてください。

于 2009-06-30T14:40:23.327 に答える
0

いつものように、Albert Kallal から素晴らしい回答が得られました。

SQL Server へのアップサイジングを検討する場合は、SQL Server グループのツールがあります。Access 用 SQL Server Migration Assistant (SSMA アクセス) http://www.microsoft.com/sql/solutions/migration/access/default.mspx は、Access アップサイジング ウィザードよりも優れています。

また、Microsoft Access のヒント ページ ( http://www.granite.ab.ca/access/sqlserverupsizing.htm ) の SQL Server アップサイジングに関するランダムな考えも参照してください。

投稿へのコメントからわかるように、組織が使用する変更管理という用語は、伝統的ではなく、かなり興味深いものです。何年も前に、データを変更するリモートオフィスの解決策を見つけようとした誰かがどのようにこの解決策を思いついたかを見ることができます. それが息苦しくなることもわかります。

于 2009-06-30T19:02:13.707 に答える