- ベストアンサー
ACCESSのレスポンスが悪い原因は何か？
- ACCESSで顧客データベースを作成しています。データ数は約6,000件で、テーブル数は19です。データベースAとB、Cがあります。
- データベースAにはテーブルのみで、データを蓄積する目的のみに使用されています。Aはサーバー上にあります。
- データベースBはデータ入力用であり、フォームの保存や開く際に時間がかかることがあります。レスポンスが悪くなる原因は何か？
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
何か、フォーム側の処理で重い事をしているのでしょうかねぇ。 例えば、インデックスが効かない様な重いクエリを作ってしまって、その結果を表示させたりしてるんじゃないでしょうか。 あるいは、クエリ中でテーブルの結合の仕方をミスって、すんごい量のレコードを引っ張ってくるようになってしまっているとか。 そうであれば、クエリの部分を出来るだけ軽くすればいいんですよね。 あとは、ネットワークに流れるデータ量を最小にすることです。高々６千件のデータ量であっても、複数人数が同時に使うとなると、かなりのトラフィックになります。 レコードソースにテーブル名を指定しただけの単純なフォームだと太刀打ちできないかもしれません。(だって、フォームを開いたすべての人に、要りもしないデータを６千件、送りつけるんですよ。) もし入力専用のフォームでしたら、プロパティの「データ入力用」を設定してやればいいでしょう。 入力も照会もというのであれば、例えば、こんな感じにするといいでしょう。 まず、検索用フォームと表示/入力用フォームとを分けて作ります。 表示/入力用フォームは常にデータを１件だけ表示するようにします。(顧客No等で絞り込んだSQLを、フォームのレコードソースに設定します。) フォームに他の人のデータを表示したいときには、 検索用フォームを起動して、条件で絞り込んで検索→該当する人を一覧表示(*1)→その中から一人を選ぶ→選んだ人を表示するようなSQLを組み、表示用フォームのレコードソースに設定する。 ってな感じでしょうか。 *1:絞込みをする際に、Top句を使用すれば、大量のデータが返ってくるような検索条件を指定されても、重くなる前に対処できます。 まずは、重いクエリを軽くすること、次に、ネットワークのトラフィックを最小にすること。この二つを行えば、かなり快適になると思うんですが。
その他の回答 (1)
- taka_tetsu
- ベストアンサー率65% (1020/1553)
>・Aはローカルではなくサーバー上にある これのせいとか、最適化してないとか。 というか、最初は速かったんですか？
お礼
最適化は終了の時にするようにしています。 クエリの見直しをしたら、かなり早く動くようになりました。 ありがとうございました。
お礼
クエリの見直しをしたら、かなり早く動くようになりました。 あとはネットワークに流れるデータ量の方も最小にできるよう頑張ってみたいと思います。 ありがとうございました。