我想知道是否有人对我有任何建议，基本上我们使用一个文本框来做搜索，但它会引起一些问题。我们有一个列表框，其rowsource设置为相当于select * from tblSearch where searchField Like "" &(形式),[frmNames] ! [txtSearch]。(文本)," "
这个查询的最大行数设置为25，所有的表都是SQL Server的链接表。在搜索文本框的On Change事件上，它在列表框上运行一个查询，一切似乎都工作得很好，除了数据库每天都为用户挂起，这让我发疯!
从本质上看，我把它归结为Access将选择语句发送给SQL(在同一台服务器上)，但不等待每个查询完成并在继续之前处理它。因此，在Access从服务器获得响应之前，用户键入下一个字符并向SQL发起一个新的查询。在SQL Server中，然后你发现挂起查询与资源等待"ASYNC_NETWORK_IO"，我理解的是客户端不从SQL Server消费数据。
我必须做的是改变事件被用于查询从更改到更新后，这真的带走了整个用户体验有一个排序或"谷歌即时"搜索体验，因为他们必须键入并按Enter之前看到的结果，不太好!
所以这就是问题所在，只是想知道是否有人有任何建议，我现在已经没有想法了!
这里的想法是保持查询结果精简和平均。每次在Access中运行此查询时，很容易是数百次，如果不是数千次(使用OnChange事件和超过1个用户)，您希望通过管道的次数尽可能少。您可以执行许多优化以使SQL查询及其结果更快:
- 将
SELECT * FROM ...更改为SELECT [column1],[column2],[etc] FROM ...(其中列仅为ListBox所需的列)。即使您正在查询的表只有您需要的列，这仍然是最佳实践，因为当您在3-12个月后再次查看它时，它很清楚，它节省了数据库引擎(在Access或SQL中)查找表中的列。 - 确保在SQL Server数据库的
searchField列上有索引。 - 将查询移动到SQL Server的视图中，并将
SELECT TOP 25...放在那里。即使你把最大行数25在访问，它仍然可以拉更多(即所有)，然后过滤到25。此外，通过将其放在视图中，您可以将WITH (NOLOCK)放在表的末尾(名称/别名)，给SQL Server提示它不需要为此查询锁定表上的任何内容。这加快了速度，特别是如果有多个用户频繁请求。
根据你的具体情况还有其他的事情，但是这些肯定会减少你的挂起时间。