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

问题描述：

涉及的代码是ADO/VB6。

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

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

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

我不知道要放多少代码放在这里，没有什么复杂的;它基本上;

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

我一直在看在探查但是这并没有给出任何线索，除了偶尔看到“SET NO_BROWSETABLE ON” /“SET NO_BROWSETABLE OFF”出现的语句之前和SP运行之后。

我搜索了网络，但无法找到任何满意的帮助;我愿意在这一点上尝试任何事情（除了在.NET重写，不幸的是，这不是一种选择！）

几个问题：您是否在超过一段时间或即刻过期后才获得超时？如果很长一段时间，探查者是否同意命令的持续时间很长？ – 2009-05-22 17:10:20

获取超时经过一段时间 - 大约30秒后过期 - 我猜测超时设置是什么，可能是默认设置。是的探查器同意 - 在VB6代码中抛出错误后，您将看到探查器中的sp完成，并记录了很长的持续时间。 – DannykPowell 2009-05-22 21:51:21

您是否确定解决方案，因为我处于similer情况！ – 2010-08-15 04:17:01

答

我觉得你已经在想这个了。没有冒犯，但是如果你使用的是MSSQL，就像有人让查询窗口打开并且它关联了数据库一样简单。这很容易测试。我以前遇到过同样的麻烦。我在没有超时的情况下运行了存储过程，通常会立即运行，但会过夜而不运行。只有找到另一名员工打开查询窗口。关闭他们的窗户，并最终运行它。检查一下，你会惊讶什么表锁可以做你的应用程序。

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

答

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

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

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

相关推荐