存储过程超时 - 但从SSMS运行时很好

Question

我有一个存储过程错误，“Timeout expired”。

涉及的代码是ADO / VB6。

存储过程本身不是问题，您可以在查询窗口中运行它并且只需不到一秒钟。

用于获取连接等的代码也是模块化的，并且在大量应用程序中使用。只有在这一个地方才会在一个特定的数据库上发生超时。

每次尝试的次数都会重现错误，无论是否在调试中运行VB6代码，然后突然一切都会神奇地重新开始工作。然后在未来的某个时间，同样的问题将再次出现。

我不确定要放多少代码，这没什么复杂的;它基本上是;

Set adoCommandObject.ActiveConnection = ...{open ADODB.Connection object}
Set rs = CreateObject("ADODB.Recordset")
Call rs.Open(adoCommandObject, , adOpenForwardOnly, adLockReadOnly)'Timeout occurs here

我一直在分析器中观看但是没有给出任何线索，除了偶尔在sp运行之前和之后看到“SET NO_BROWSETABLE ON”/“SET NO_BROWSETABLE OFF”语句。

我搜索了网但未能找到任何令人满意的帮助;我愿意在这一点上尝试任何事情（除了在.NET中重写，不幸的是，这不是一个选项！）

Answer 1

我认为你在考虑这个问题。没有进攻，但是如果你使用的是MSSQL，那就像有人打开查询窗口那样简单，它会占用数据库。这很容易测试。 我之前遇到过同样的麻烦。我之前运行存储过程没有超时，通常会立即运行但是会在一夜之间运行而不会运行。只有找到另一名员工才打开他们的查询窗口。关闭他们的窗口和poof它终于运行。 看看这个，你会惊讶于表锁可以对你的应用程序做什么。

我这样说是因为你说问题是间歇性的。它来来去去。我怀疑桌锁。无论是应用程序正在执行此操作，还是由另一个用户向数据库发出查询。如果不是其他用户，请检查以确保您的应用程序每次使用时都关闭与数据库的连接。

Answer 2

• 也许有一些潜伏的代码意外地将连接或命令的超时设置为一个非常小的值。
• 也许这个过程确实需要一段时间才能运行，例如如果服务器正在做其他事情或统计数据已过期
• 您是否可以使用探查器捕获超时的情况，如果是这样，proc实际上需要很长时间才能执行？

如上所述here SET NO_BROWSETABLE ON类似于在选择中使用FOR BROWSE。我猜它是由ado自动生成的，当它认为你可能想要更新该记录集时。你可以设置Recordset的一个属性来阻止那些被发布的属性，但似乎不太可能是问题所在。