従来の MS Access アプリケーションは複数のユーザーをサポートする必要がある

Question

私は現在、従来の MS Access アプリケーションの開発とメンテナンスを担当する 4 人チームに所属しています。

このアプリケーションは非常に大規模で、数百のフォーム、レポート、クエリ、テーブルが含まれています。

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

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

これは、アプリケーションのすべてのユーザーが、変更を行うためのデータベースの独自のローカル コピーを持っていることを意味します。当社には、慎重に変更が管理された環境があり、一度にデータを操作できるのは 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 でどのように表現されますか?

Answer 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 アクセスをマルチユーザーにするのではなく、MS アクセスはそのままマルチユーザーになります。また、別の場所にいるユーザーがアプリケーションを使用できるようにするいくつかのテクノロジーを採用すること以外は、何もする必要はありません。つまり、これが TS の機能であり、SQL Server も行うことができます。

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

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

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

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

Answer 2

IMOあなたは間違いなくかかわらず、あなたが考える他のどのようなソリューションのマルチユーザ・サーバにデータベースを変換する必要があります。有用であることが分かるはずですアップサイジングウィザードがあります（ http://support.microsoft.com/kb/237980）、あなたはおそらくアクセスが可能になり、SQLサーバーにはないが、ほとんどの部分は無痛であるべき項目に遭遇します。 あなたは（たとえばODBC経由）、この新しいデータ・ソースを使用するようにローカルアクセスコピーを指すことができますし、私はそれがすべて同じようにほとんどが動作するはずと信じています。年間でこれを行っていない、これらのフィールドのバリデーションルールは（彼らはまだ、フォーム上のではないでしょうか？）何何のアイデアはに判明していないでしょう。あなたは、SQLサーバーの試用版をダウンロードし、それが必要になりますどのくらいの努力の感覚を得るために時間の下にこれをで行うことができます。

Answer 3

いつものように、あなたはアルバートKallalから優秀な答えを持っています。

あなたはSQL Serverへの大型化を検討したい場合は、

SQL Serverグループからのツールがあります。 アクセス用のSQL Serverの移行アシスタント（SSMAアクセス） http://www.microsoft.com/sql/solutions/migration/アクセスアップサイジングウィザードよりも優れているアクセス/ default.mspxするます。

また、でhttp Microsoft AccessのヒントページからSQL Serverのアップサイジングの私のランダムな思考を参照してください。 //www.granite.ab.ca/access/sqlserverupsizing.htmする

あなたは、あなたの組織で使用される用語変更制御を投稿するコメントから見ることができるように非伝統的とかなり面白いです。私は誰かの年前にリモートオフィスへの解決策を把握しようとどのように見ることができますが、変更するデータは、この解決策を考え出すだろう。私もそれは息苦しいだろうかかかわらず、見ることができます。