約5人のユーザーグループで、フロントエンド/バックエンドの分割構成としてセットアップされたMSAccess2003アプリケーションを作成しました。フロントエンド.mdbはネットワークファイルサーバー上にあり、すべてのクエリ、フォーム、レポート、VBAコードに加えて、バックエンド.mdb内のすべてのテーブルへのリンクと、AS/などのODBCデータソースへのリンクが含まれています。 400。バックエンドは同じネットワークファイルサーバー上にあり、テーブルデータが含まれているだけです。
これは、私が「ライブ」になり、少数のユーザーが拡張リクエストやバグレポートなどを考え出すまではうまく機能していました。フロントエンドの.mdbの独自のコピーで開発/テストすることにより、新しいコードを展開しています。別のネットワークフォルダー（同じバックエンド.mdbにリンクされている）、完成したファイルを「come-and-get-it」フォルダーに投稿し、ユーザーに警告すると、ユーザーは新しいフロントエンドをコピーして貼り付けますネットワーク上の独自のフォルダにファイルします。このようにして、各ユーザーは、全員を一度に起動しなくても、「停止点」にいるときにフロントエンドを更新できます。
私が今開発しているとき、時々Accessが非常に遅くなることがわかりました。たとえば、フォームを作成してプロパティボックスのドロップダウンをクリックしようとすると、ドロップダウン矢印が押し込まれますが、オプションのリストが表示されるまでに数秒かかります。または、フォームのコントロールの選択と移動には多くの遅れがあります。または、キーボードの遅延がたくさんあります。
その後、他の時間には、ラグはまったくありません。
他のユーザーと同じバックエンドにリンクしているからなのかしら。必要に応じて、レコードのロックを最小限に抑えて、クエリ、フォーム、レポートなどを設定するために合理的な努力をしました。しかし、私は何かを見逃した可能性があります。あるいは、対処する必要のある他のパフォーマンスの問題があるかもしれません。
しかし、自分の開発バックエンド.mdbをセットアップするためのさらに良い方法があるかどうか疑問に思っているので、他のユーザーと同じライブデータではなく、「安全な」データでコードをテストできます。 。恐らく最悪の瞬間に、いくつかのデータを破壊するのは時間の問題だと思います。
明らかに、別のバックエンド.mdbを設定し、Linked Table Managerを使用して、毎回フロントエンドのテーブルリンクを手動で再構成することができます。しかし、私はそれよりもエレガントな解決策があることを望んでいます。
そして、このマルチユーザーの分割データベース構成で考慮すべき他のパフォーマンスの問題があるかどうか疑問に思っています。
編集：私はMS Access（MS-SQLやその他の「実際の」バックエンドではない）で立ち往生していることを追加する必要がありました。詳細については、この投稿への私のコメントを参照してください。