データベースのコンパクトとアーカイブ-MSアクセスバックエンド

Question

シナリオ: ：レガシープログラム（どの言語がわかりません）があり、「データベース内のフォームをコンパクトおよびアーカイブする」ように求められています。ユーザーがアプリケーションを開いた瞬間、約2〜5分かかり、約27000のレコードをロードします!!!私の理論では、新興企業のすべてのレコードをロードしているが、それが唯一の理由ではないかもしれないということです。いくつかの掘削を行い、正しいように見えるアクセスバックエンドを見つけた後、私は会社内の15+の他の株式に同じアクセスファイルを見つけました。現在、このアプリケーションは1997年頃にアクセスが標準だったと推測しているときに作成されましたが、15以上のアクセスデータベースからデータを取得しているのでしょうか？このプログラムをスピードアップする標準と思われるのは、古いレコードを別のアクセスデータベースにアーカイブすることです（そのため、起動時にすべてをロードしていると考えています。

質問: ：私は月曜日にプログラムについて話し合うために会議を開き、誰かがいくつかの有用な質問、理論、解決策などを提案できるかどうか疑問に思っていました。それは私自身でこれを行うことができないということではありません。 。また、もう1つの楽しい事実は、請負業者によって作成されており、コードがずっと前に失われた可能性があるため、ソースコードを取得できる場合とできない場合があります。

サイドノート: ：Auto-Archiveの古いレコードへのアクセスが可能ですか？それは、それらをxxxarchと呼ばれる別のdbに転送することを意味します。

前もって感謝します。私はあなたが持っているどんな質問にも答えようとします。

編集:

この状況に関する最新情報が表示されます。

1つのデータベースをメインとして、もう1つはアーカイブするデータベースを使用しているように見えます。アプリケーションを開くためにまだ独自のユーザーアカウントを持っていることはまだありませんが、データベースを調べると、ログインIDと同じパスワード（パスワード）があるユーザーテーブルがあります。データは何も変更しません。選択したとき、私はほぼ即座にデータを取得することができ、他のユーザーが取得している減速のどれも見られませんでした。私はまだソースコードを見ていませんが、私が伝えることができることから（exeを取得してメモ帳に置く）から、それはVBAでコード化され、おそらくMS Accessを使用して作成されたようです。また、アプリケーションはデータフォルダーにtemp.mdbを作成するようです。現在、何もありません。テーブルも何もありません。これがユーザーを遅くしているものであり、パフォーマンスを改善するために削除することができると仮定しています。ソースコードを取得したら、別の更新を投稿し、何が減速しているのかをよりよく理解します。

Answer 1

考慮すべきいくつかのこと：

アクセス（MDB）データベースは、頻繁に使用している場合にタイトルに記載されているように、定期的なコンパクト/修理が必要である傾向があります。しかし、私はそれがパフォーマンスを最小限よりも高めるのに役立つことはめったにありませんでした。それが本当に長い時間だった場合、ファイルは本当に大きく膨らむ可能性があり、それがユーザーが遅いネットワーク接続でそれにアクセスしている場合、それが問題の一部かもしれません。

誰かがあなたの会社またはこのフォーラムで、SQL Serverのような「より大きな」DBにアップグレードすることを提案するつもりです。問題を分離するまで、またはパフォーマンス以外の理由がない限り、それをしないでください。問題は、アプリケーションの設計やDBアーキテクチャの不十分なものによって引き起こされる合理的な可能性があります。アプローチを変更せずに、より強力なツールを問題に投げることは、役立つ可能性は低いです。

アクセスDBは、データを最大限に活用するずっと前に、同時ユーザーを最大限に活用します。多くのユーザー（30+）はシステムの使用を開始しましたか？それは問題の一部かもしれません。

古いレコードのアーカイブ：これを行うために何かを構築する必要があります。良いニュースは、それほど難しいことではないということです。

15以上のデータベースへのアクセス：フロントエンドGUIがアクセスして書かれていないことを確認してください。これは、ネットワーク上の中央MDBデータファイルに接続するエンドユーザーマシン（どこでもコピー）にMDBフロントエンドをロードするためのアクセスを備えた一般的なアーキテクチャです。伝える最良の方法は、データベースを開き、テーブルのみ、またはテーブル +フォーム/レポートが含まれているかどうかを確認することです。

Answer 2

私には、あなたの最初のビジネスの注文はこの問題を解決することであるべきです。

請負業者によって作成され、コードがずっと前に失われた可能性があるため、ソースコードを取得できる場合とできない場合があります。

現在のように、あなたは私たちに、実際に何が起こっているのかについての知識なしに、遅さの原因と救済について推測するように私たちに求めています。

Answer 3

ソースコードがない場合、バックエンドデータベースをSQL Serverに変更することはできません。

ただし、実際にデータファイルにアクセスしていて、それらを編集できる場合は、インデックスを確認してみませんか？ 27Kレコードは、アクセスを含むデータベースに対して些細なことであり、データの読み込みが遅くなることは、テーブルが単に適切にインデックス化されていないことを示唆しています。テーブルを調べて、明らかなフィールドにインデックスが表示されない場合は、それらを追加して、それが物事を高速化するかどうかを確認してください。

そうでない場合、アプリがひどく設計されていることを意味し、ソースコードが不足しているため、それについてできることはあまりありません。

上記のすべては、もちろん、ネットワーキング環境がアクセス/ジェット/エースに適していると仮定しています。つまり、これらのデータベースファイルが有線LAN以外にアクセスされている場合、それについては何もできません（WANとWiFiはJET/ACEのために完全に外出しています）。

最後に、アーカイブのテーマについては、ハードウェア/ソフトウェアの厳しい制限に対して実際に実行されていない限り、データをアーカイブする正当性はないと思います。この場合、あなたはそれにさえ近いものではありません。