慢查询，以前不是问题 [英] slow queries, didn't used to be a problem
问题描述
大家好，
我有一个地址字段，在After Update事件后，搜索数据库以查看我刚输入的地址是否已存在于数据库中。此搜索过去只在第一个新记录条目上花了一点时间。从那时起，只要我保持数据库打开，这个搜索几乎是即时的。
我也有一个按钮，当我输入一个新的记录时我点击其他事情，为记录分配文件号。它不使用自动编号字段。它的作用是在数据库中搜索最高的现有文件编号并添加1.此搜索过去也几乎是即时的。
突然有一天，大约两周前，这两个都是搜索开始永远。我必须等待将近30-40秒进行地址搜索，并在一两分钟内进行文件编号搜索。
可能导致此问题的原因是什么？我检查以确保字段已编入索引。它们是。
Hi all,
I have an "Address" field that, upon an After Update event, searches the database to see if the address I just entered already exists in the database. This search used to only take a little while on the first new record entry. From then on, as long as I kept the database open, this search was practically instantaneous.
I also have a button that I click when I am done entering a new record that, among other things, assigns a file number to the record. It does not use an autonumber field. What it does is search the database for the highest existing file number and adds 1. This search also used to be nearly instantaneous.
Suddenly one day, about two weeks ago, both of these searches started taking forever. I have to wait nearly 30-40 seconds for the address search, and over a minute or two for the file number search.
What might have caused this? I checked to make sure that the fields are indexed. They are.
推荐答案
这是统一数据库还是拆分（前端/后端）数据库？它是独立的还是在网络上运行？我问，因为它确实听起来像一个网络问题，假设您的设置没有其他任何改变，访问方式。
我们可能还需要查看您正在使用的代码支票。
Linq; 0）>
Is this a unified database or a split (front end/back end) database? Is it a stand-alone or does it run on a network? I ask because it really sounds like a network problem, assuming nothing else had changed in you setup, Access-wise.
We probably also need to see the code you''re using for the check.
Linq ;0)>
这是一个统一的数据库还是拆分（前端/后端）数据库？它是独立的还是在网络上运行？我问，因为它确实听起来像一个网络问题，假设您的设置没有其他任何改变，访问方式。
我们可能还需要查看您正在使用的代码支票。
Linq; 0）>
Is this a unified database or a split (front end/back end) database? Is it a stand-alone or does it run on a network? I ask because it really sounds like a network problem, assuming nothing else had changed in you setup, Access-wise.
We probably also need to see the code you''re using for the check.
Linq ;0)>
这可能是。它是前端/后端，后端在服务器上。其他任务稍慢，如打印（联网打印机）等。但它们看起来几乎没有上面列出的搜索那么慢（与通常的速度成比例）。它表现得好像它没有索引。
如果您认为看到代码可能有所帮助，我可以尝试明天为您准备。
感谢您的帮助。我将查看服务器问题。
That may be. It is a front end/back end, with the back end on a server. Other tasks are slightly slower, such as printing (networked printer), etc. But they don''t seem nearly as slow (in proportion to their usual speed) as the searches listed above. It''s acting as though it''s not indexing.
If you think seeing the code might help, I can try to get it for you tomorrow.
Thanks for the help. I will look into the server question.
以下是运行速度超慢的两位代码。运行任何其他程序的服务器似乎没有任何缓慢。
注意：SC_NEW是用于输入新订单以及用于输入和存储具有报价订单的表尚未获得批准。当新订单被批准时，它将被移动到未结订单（SC_OPEN表）。订单完成后，它将移至已存档的订单（SC_ARCH）。因此，这两位代码搜索有三个表。
这是检查重复地址的代码。即使在SC_NEW表的ADDRESS字段中也是AfterUpdate：
Here are the two bits of code that are running super slow. There doesn''t seem to be any slowness to the server running any other programs.
Note: SC_NEW is a table for entering new orders, and for entering and storing quoted orders that have not yet been approved. When a new order is a go-ahead it gets moved to the open orders (SC_OPEN table). Once an order has been completed, it gets moved to the archived orders (SC_ARCH). So there are three tables that these two bits of code search.
This is the code that checks for duplicate addresses. It is an AfterUpdate even in the ADDRESS field on the SC_NEW table:
这篇关于慢查询，以前不是问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
