MS Access 2007 をフロント エンドとして使用しており、SQLServer 2008 R2 バックエンドにすべてのリンク テーブルがあります。
Access のフォームで、特定のフィールドに特定の値を持つレコードを検索する目的で、リボンで、またはフォームにボタンを作成して、FIND ボタンを実行しようとしています。
FIND ウィンドウの入力を完了したら、[次を検索] をクリックします。場合によっては、レコードがすぐに見つかります。他のものでは、何も見つからないことを報告するだけで何時間もかかることがあります（私がそうすべきだとわかっている場合）。
私が探しているテーブルには、約 99,000 のレコードが含まれています。フィールドがインデックス化されているかどうかは問題ではないようです。
私が間違っていることがありますか、それとも Access がこれを処理できないのでしょうか? また、複数の検索要求を処理し、情報を Access the answer に渡すストアド プロシージャを作成していますか?
find メソッドは、ODBC データ ソースでは遅いことが知られています。Access 2007Recordset.FindFirstメソッドのヘルプ トピックには次のように記載されています。
Microsoft Access データベース エンジンに接続された ODBC データベースと大規模なダイナセット タイプの Recordset オブジェクトを操作しているときに、Find メソッドを使用したり、Sort プロパティや Filter プロパティを使用したりすると速度が低下することがあります。パフォーマンスを向上させるには、カスタマイズされた ORDER BY または WHERE 句、パラメーター クエリ、または特定のインデックス付きレコードを取得する QueryDef オブジェクトを含む SQL クエリを使用します。
さらに、Access フォームを 99K レコードのレコード ソースにバインドすると、パフォーマンスが低下します。フォームのレコード ソースとしてクエリを使用し、1 行または数行のみを返すようにクエリを設計します。
別の行セットを選択するオプションをユーザーに提供し、ユーザーの選択を反映するようにフォームのレコード ソース プロパティを変更します。
これは、必要な検索のタイプと、検索する列（フィールド）のデータ型によって異なります。たとえば、インデックス付きの列にテキストデータ型があり、[フィールドの開始]または[フィールド全体]を使用して検索すると、非常に高速になりますが、フィールドの任意の部分を検索すると、転倒する可能性があります。つまり、Accessが検索にインデックスを使用できる場合は、非常に大きなテーブルでも機能します。そうでない場合は、ストアドプロシージャを使用するのが最適ですが、インデックスがなくても高速になるとは思えません。