1

誰かが私に何かアドバイスがあるのだろうか、基本的に私たちは検索を行うためにテキストボックスを使用していますが、それはいくつかの問題を引き起こしています。select * from tblSearchと同等に設定されたrowsourceのリストボックスがあります。ここで、searchField Like " "＆[Forms]！[frmNames]！[txtSearch]。[Text]＆ " "

このクエリの最大行数は25に設定されており、すべてのテーブルはSQLServerにリンクされたテーブルです。検索テキストボックスのOnChangeイベントでは、リストボックスで再クエリが実行され、データベースが毎日ユーザーのためにハングしていることを除いて、すべてがうまく機能しているように見えます。

これを本質的に調べてみると、Accessはselectステートメントを（同じサーバー上の）SQLに送信していますが、各クエリが完了して処理するのを待ってから先に進むことはありません。したがって、Accessがサーバーから応答を返す前に、ユーザーは次の文字を入力し、SQLに対して新しいクエリを実行します。SQL Serverでは、リソース待機「ASYNC_NETWORK_IO」でハングしたクエリが見つかります。これは、クライアントがSQLServerからのデータを消費していないことを理解しています。

私がしなければならなかったのは、再クエリに使用されるイベントをOnChangeからafterupdateに変更することです。これにより、表示する前にEnterキーを押して入力する必要があるため、並べ替えや「GoogleInstant」検索エクスペリエンスのユーザーエクスペリエンス全体が失われます。結果、良くない！

だからそれが問題です、誰かが何か提案があるかどうか疑問に思っています、私は今アイデアを使い果たしました！

4

1 に答える 1

1

ここでの考え方は、クエリ結果を無駄のない平均的なものに保つことです。 このクエリがAccessで実行されるたびに、数千回とまではいかなくても数百回になります（OnChangeイベントがあり、ユーザーが1人以上の場合）。パイプを通過する回数をできるだけ少なくする必要があります。SQLクエリとその結果を高速化するために実行できる最適化はいくつかあります。

  1. 次のように変更SELECT * FROM ...しSELECT [column1],[column2],[etc] FROM ...ます（列はリストボックスに必要な列のみです。クエリしているテーブルに必要な列しかない場合でも、3〜12か月間もう一度見ると明確であるという点で、これはベストプラクティスです。後で、dbエンジン（AccessまたはSQLのいずれか）がテーブルの列を検索する必要がなくなります。
  2. searchFieldSQLServerデータベースの列にインデックスがあることを確認してください。
  3. クエリをSQLServerのビューに移動し、SELECT TOP 25...そこに配置します。MAX ROWS 25をAccessに配置した場合でも、さらにプル（つまり、ALL）してから25にフィルター処理できます。また、ビューに配置することWITH (NOLOCK)で、テーブル（名前/エイリアス）の最後に次のように配置できます。 SQL Serverは、このクエリのためにテーブル上で何もロックする必要がないというヒントです。これにより、特に複数のユーザーが頻繁に再クエリを行う場合に処理が高速化されます。

特定の状況に応じて他のこともありますが、これらは間違いなくハングタイムを短縮します。

于 2013-05-06T17:28:42.707 に答える