7


9

私は、約5人のユーザーグループで、フロントエンド/バックエンドの分割構成としてセットアップされたMS Access 2003アプリケーションを作成しました。 フロントエンドの.mdbはネットワークファイルサーバー上にあり、すべてのクエリ、フォーム、レポート、VBAコード、バックエンドの.mdb内のすべてのテーブルへのリンク、およびAS / 3などのODBCデータソースへのリンクが含まれています。 400。 バックエンドは同じネットワークファイルサーバー上にあり、テーブルデータを持っています。

これは私が "稼働"して、私の一握りのユーザーが機能強化要求やバグ報告などを思いつくようになるまではうまくいきました。 私は自分自身のコピーのフロントエンドの.mdbを別のネットワークフォルダ(同じバックエンドの.mdbにリンクされています)で開発/テストし、完成したファイルを "come-out"ファイルに投稿することによって新しいコードを展開しました。ユーザーに警告し、ユーザーは新しいフロントエンドファイルをネットワーク上の自分のフォルダーにコピー/貼り付けします。 このようにして、各ユーザーは、一度に全員をブートアウトしなくても、「停止地点」にいるときにフロントエンドを更新できます。

私が今開発しているとき、時々アクセスが極端に遅くなることを私は見つけました。 同様に、フォームを開発してプロパティボックスのドロップダウンをクリックしようとすると、ドロップダウン矢印が押し込まれますが、オプションのリストが表示されるまで数秒かかります。 あるいは、選択にはかなりの遅れがあります。 またはキーボードがたくさん遅れます。

そして、他の時には全く遅れがありません。

私は他のユーザーと同じバックエンドにリンクされているからだと思います。 私はクエリ、フォーム、レポートなどを設定するために合理的な努力をしました。 必要に応じて、あるとしても最小限のレコードロックで。 しかし、私は何かを逃したかもしれません、あるいは私が対処する必要がある他の何らかのパフォーマンス問題があるかもしれません。

しかし、私が自分自身の開発バックエンド.mdbを設定するためのもっと良い方法があるのではないかと私は思っています。 。 おそらく最悪の場合、データを破壊するのは時間の問題です。

明らかに、私は別々のバックエンド.mdbを設定し、毎回リンクテーブルマネージャを使ってフロントエンドのテーブルリンクを手動で再設定することができます。 しかし、私はそれよりもっとエレガントな解決策があることを願っています。

そして、このマルチユーザーの分割データベース構成で考慮すべきパフォーマンス上の問題が他にあるかどうか疑問に思います。

編集:私は私がMS Access(MS-SQLや他の「本物の」バックエンドではない)で立ち往生していることを付け加えたほうがよい。詳細については、この記事に対する私のコメントを参照してください。

8 Answer


12


すべてのユーザーがフロントエンドを共有している場合、それは間違った設定です。

各ユーザーはフロントエンドの個別のコピーを持つ必要があります。 フロントエンドを共有すると、共有フロントエンドが頻繁に破損したり、フロントエンドのフォームやモジュールが奇妙に破損したりすることがあります。

A2000以降、エンドユーザーが使用しているのと同じフロントエンドのコピーでどのように開発できるのかは私には明らかではありません。システムテーブルの1つの単一レコード内の単一BLOBフィールド内)

私は実際に問題が生産データを使用することによって引き起こされるとは思いません(他の人が言ったように、生産データに対して開発することはおそらく良い考えではありませんが)。 私はそれらが悪いコーディング慣習とあなたのフロントエンドコードの維持の欠如によって引き起こされると思います。

  1. VBEオプションでCOMPILE ON DEMANDをオフにします。

  2. 必ずOPTION EXPLICITが必要です。

  3. コードを数行おきに頻繁にコンパイルする - これを簡単にするために、COMPILEボタンをあなたのVBEツールバーに追加する(私がそれをしている間に、CALL STACKボタンも追加する)。

  4. フロントエンドのバックアップを定期的に作成し、コードを逆コンパイルして再コンパイルしてください。 これは、/ decompileスイッチを使用してAccessを起動し、フロントエンドを開き、Accessを閉じ、Accessでフロントエンドを開き(スタートアップコードを回避するためにShiftキーを押したまま)、次に逆コンパイルしたフロントエンドを(SHIFTを押しながら)圧縮することによって実現されます。キーを押したままプロジェクト全体をコンパイルし、最後に1つ圧縮します。 メジャーコードリリースの前にこれをするべきです。

他のいくつかの考え:

  1. あなたはそれがWindowsサーバーであるかどうかは言わない。 SAMBA経由でアクセスされるLinuxサーバーは過去に問題を抱えていましたが(Windowsサーバーよりもはるかに速いと言う人もいますが)、歴史的にNovellサーバーはJetファイルを確実に編集できるよう設定を調整する必要がありました。 物事をより良くするためにWindowsサーバー上で調整できるいくつかの設定(OPLOCKSのような)もあります。

  2. Jet MDBを短いパスの共有に保存します。 \ Server \ Data \ MyProject \ MyReallyLongFolderName \ Access \ Databases \は\ Server \ Databasesよりもデータの読み取りがはるかに遅くなります。 これは本当に大きな違いを生みます。

  3. リンクテーブルは、古くなる可能性があるメタデータを格納します。 2つの簡単なステップとそれを修正するために取られるべき1つの抜本的なステップがあります。 まず、後端を圧縮してから、前端を圧縮します。 それは簡単なことです。 それでも解決しない場合は、リンクを完全に削除して最初から作り直してください。

  4. MDBではアンコンパイルできないため、MDBではなくエンドユーザーにMDEを配布することを検討することもできます。

  5. その他の一般的なパフォーマンス情報については、http://www.granite.ab.ca/access/performancefaq.htm [Tony Toews’s Performance FAQ]を参照してください。


2


1)コードhttp://www.mvps.org/access/tables/tbl0009.htmからAccessテーブルを再リンクします。

新しいMDEをユーザーに公開する準備ができたら、テーブルを再リンクし、MDEを作成してMDEをサーバーにコピーします。

2)無料の自動FEアップデーターユーティリティを特別に作成したので、私は望むだけ頻繁にFE MDEに変更を加えることができ、次回誰かがアプリを実行しに行ったときに最新の情報を取得できると確信しています。バージョン。 エラーやAuto FE Updaterユーティリティの詳細については、各PCのFEを最新の状態に保つために、私のWebサイトのhttp://www.granite.ab.ca/access/autofe.htmにある無料のAuto FE Updaterユーティリティを参照してください。 。

3)クライアントの現場で作業しているときは、全員がシステム外に出てから数時間後にテーブル構造を更新します。 HOW TO:Access 2000でユーザーのアイドル時間または非アクティブ状態を検出する方法(Q210297)http://support.microsoft.com/?kbid=210297 ACC:ユーザーのアイドル時間または非アクティブ状態を検出する方法(Q128814)http://support.microsoft .com /?kbid = 128814

しかし、タイマーイベントで実行されるコードはプログラマにとって無効にする必要があることがわかりました。 そうでなければ、コードを編集しているときに奇妙なことが起こり始めます。

また、印刷プレビューでは、レポートをExcelまたは他のユーザーにエクスポートするためのメニュー項目をユーザーが実行できないことがあります。 そのため、プレビューされたレポートを右クリックして、レポートにエクスポートするために何らかの種類の内部フォーカスをレポートに戻す必要がありました。 これはタイマーを5分に延長することによっても助けられました。

タイマーを5分に延長することのマイナス面は、ある人がその日のかなりの部分で同じ形式で同じコントロールにいる場合、つまり同じ問い合わせをしている場合、そのルーチンは彼らが実際に何かをしたことに気づかなかった。 プログラムで何かをするときはいつでもこのタイマーをリセットするためにいつか論理を入れるつもりです。

4)他の人がスクリプトについてコメントしたりスキーマを更新したりすることについてはCompare’Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htmを参照してください。 癖がありますが、テーブル、フィールド、インデックス、およびリレーションシップを更新するためのVBAコードを作成します。


1


devからprodに切り替えるときは、VBAを使用してテーブルを新しいターゲットにリンク解除し、再度リンクします。 構文を覚えるのは私にとって長い年月を経てきました - 私はちょうどその関数が書くのが簡単だったことを知っています。

または、MS-Accessを使用して、ODBC、またはクライアントmdbの外部にある他のデータ接続を介してMS-Accessと通信します。

すべてのファイルベースデータベースと同様に、ピーク使用時や2から30の間の小さな魔法の数を超えると、結局問題に遭遇します。

また、アクセスは頻繁に破損する傾向があるため、バックアップ、コンパクト化、修復は頻繁に行う必要があります。 このタスクを自動化するためにサードパーティ製のツールが存在していました。

パフォーマンスに関しては、データはクライアント側で処理されているので、netmeterのようなものを使用して、ネットワーク上のデータ量を監視できます。 インデックス作成とテーブルスキャンの回避に関する同じ原則が、ファイルベースDBにも適用されます。


1


他の人からのたくさんの良い提案。 これが私の2ミリセントの価値です。 私のバックエンドデータはドライブマッピングを通してアクセスされるサーバー上にあります。 私の場合は、Yドライブです。 本番ユーザーは、アクティブディレクトリを使用してログインスクリプトを介してマッピングを取得します。 それから次のシナリオはバッチファイルによって容易にされます:

  • バッチファイルでsubstコマンドを実行してローカルコンピュータに対して開発する

  • バックアップサーバーを指すようにして、昨夜のデータに対してレポートを実行します(読み取り専用)。

  • 正しいディレクトリを参照して、月末のデータに対してレポートを実行します。

  • 特別なディレクトリを保持することによって特別なシナリオに対してテストする

私の環境(平均5人の同時ユーザー、10,000行ではなく1000行)で破損が発生しましたが、まれで管理しやすいものです。 過去数年間で一度だけ、私たちは前日のバックアップを利用しました。 私達は私達のより多くの量のもののためにSQL Serverを使用しますが、おそらく私たちにはサイト上にSQL管理者がいないのでそれに対して開発するのはそれほど便利ではありません。


0


また、 この質問に対する回答のいくつかを見つけることができます。同様に役に立つように、access)からスキーマを抽出してください。 提案されている手法の1つを使用してスキーマを抽出したら、スキーマのソース管理を使用する機能や「クリーンな」テスト環境を簡単に構築できるなど、さまざまな新しいオプションを入手できます。

コメントに返信するための編集:Accessデータベースをネイティブ形式でソース管理する簡単な方法はありませんが、スキーマファイルは他のテキストファイルと同じです。 したがって、あなたは簡単なバージョン管理/ロールバックのためにあなたが選んだソース管理ソフトウェアにチェックインおよびチェックアウトすることができます。

もちろん、スキーマからデータベースを再構築するために一連のスクリプトを設定していることにかかっています。 一度実行すると、別の場所にそれを再構築するオプション/代替バージョンを作成するのは通常簡単で、以前にコミットしたスキーマのバージョンからテスト環境を構築できます。 それが少し明確になることを願っています!


0


クライアントに新しいFEをリリースしたときにバックエンドMDBスキーマを自動的に更新したい場合は、Compare’Em http://home.gci.net/~mike-noel/CompareEM-LITE/CompareEM.htmを参照してください。 VBAコードはMDBを再作成する必要があります。 または、既存のBE MDBのバージョンアップグレードを実行できるように、2つのMDB間の違いを作成するためのコード。 ちょっと風変わりですが、うまくいきます。

私はいつも使っています。


-1


データ用の共有mdbファイルは堅牢なソリューションではないことを理解する必要があります。 マイクロソフトは、SQL Serverまたは他のサーバーベースのデータベースがはるかに優れたソリューションであり、同じアクセスフロントエンドを使用できるようにすることをお勧めします。 そのようにしたい場合は、移行ウィザードを使用して切り替えを行うことができます。

別の用途が指摘するように、汚職が発生するでしょう。 それはどれほど頻繁にではなく、そうではありません。

パフォーマンスの問題を理解するには、サーバーにとって、データが含まれているmdbファイルは単なるファイルです。 サーバー上でコードが実行されないので、サーバーはトランザクション、レコードのロックなどを理解しません。 それは単に、たくさんの人が同時に読み書きしようとしているファイルがあることを知っているだけです。

SQL Server、Oracle、DB2などのデータベースシステムでは。 MySQLなど データベースプログラムはサーバー上で実行され、データベースファイルにアクセスする単一プログラムのようにサーバーに見えます。 レコードのロック、トランザクション、同時実行性、ログ記録、データのバックアップ/リカバリ、およびデータベースに必要なその他すべての処理を処理するのはデータベースプログラム(サーバー上で実行されている)です。

サーバー上で動作するように設計されたデータベースプログラムはそれだけでそれを実行するように設計されているので、Accessのようなプログラムが共有ファイル(mdb)の書き込みを読むのをはるかによく、より効率的に実行できます。


-2


ライブデータに対して開発するための2つの規則があります

_ _ 最初のルールはです。 . . ライブデータに対して開発しないでください。 今までにない。

2番目の規則はです。 。ライブデータに反して発展するときはいつでも。 今までにない。 _ _

リンクテーブルのバインディングをプログラム的に変更できるので、新しいバージョンをデプロイするときにリンクを変更するためのマクロを書くことができます。

MS Accessであるためアプリケーションは遅く、多くの同時ユーザーが好きではありません(1以上の任意の数)。