データベースサーバを導入して、クライアントサーバ環境にすればいいと思いますが・・・
ソフトの変更もあるし、費用も手間もかかるので無理かもしれませんね。

んでがす、普通にACCESSを使うと、単なるファイル共有にしかなりませんからねえ・・・。ただ、適切なindex張って利用すれば「全データ」とはならないはずですけども。

で、GIGABASEでもクライアントの数が多いようだとあまりかわんないような気がします。それより「正しいクライアント/サーバ」な形にして流れるデータ量を調整した方が、効率がいいのではないかと思います。

#とはいえ、今お世話になってるとこの作業では、40MBから50MBぐら
#いのMDB47個をファイル共有で使ってたりするので、ひとのことは
#言えない(--;

>１００ＢＡＳＥでも画面変わるたびに１０秒弱待たされる（大泣）
データの抽出方法に問題があるのかもしれません。
ORACLEでもSQLを少し弄るだけで劇的に速度が改善される場合が有るので…
ＤＢサーバの導入も効果がありますが、ロジックが悪い場合の速度低下は余り改善の効果は望めません。

まさか、テーブル全体をループで舐め回してませんよね…？

とりあえずOffice Developerを持ってるならアップサイジングウィザードを信じて
データをMSDEに移行してADPファイルにしちゃうとか...

ACCESSを利用すると最初は安くはつきますが、ここまでくると結局、作り直しとか上位SQL DB製品へ移行・・ということになってしまうんですよね。基本的にスタンドアロン構成用のDB製品かなぁと。(--;

ドライブとして認識するように増設した128MBのCFにMDBを納めてちょちょっと設定変更して、せめて読み出し速度を速くしてやるトカ・・。それでもいずれ、限界は近いでしょうけど。

それか許されるなら、サーバから定期的にクライアントマシンにMDBをコピーかけて、データ参照はクライアントマシン内で完結するように変更するとか。そうすると、更新面で同期問題がでてくるでしょうけど。

あとは非常に利用率の高い参照作業をWeb経由でアクセスするとか
データアクセスページにして基本的な作業は済ませるとか...
でも確かにクエリで全データを落としてくるような事には簡単にはならないよう気もします(^^;;

最近の１５００件位を抽出してセカンドキャッシュみたいな
アクセス方法が出来ないか聞いてみます。
アルゴリズムはさっぱりわかりませんが、どうもＨＤＤアクセスは
そんなにビジーじゃなさそうです。
ＯＳは２０００なんですが、９Ｘみたいにディスクキャッシュを
大きく設定する、なんてことは出来るのでしょうか。
アドバイスありがとうございました。