存儲過程超時 - 但從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 DannykPowell

幾個問題：您是否在超過一段時間或即刻過期後才獲得超時？如果很長一段時間，探查者是否同意命令的持續時間很長？ – 2009-05-22 17:10:20

獲取超時經過一段時間 - 大約30秒後過期 - 我猜測超時設置是什麼，可能是默認設置。是的探查器同意 - 在VB6代碼中拋出錯誤後，您將看到探查器中的sp完成，並記錄了很長的持續時間。 – DannykPowell 2009-05-22 21:51:21

您是否確定解決方案，因爲我處於similer情況！ – 2010-08-15 04:17:01

我覺得你已經在想這個了。沒有冒犯，但是如果你使用的是MSSQL，就像有人讓查詢窗口打開並且它關聯了數據庫一樣簡單。這很容易測試。我以前遇到過同樣的麻煩。我在沒有超時的情況下運行了存儲過程，通常會立即運行，但會過夜而不運行。只有找到另一名員工打開查詢窗口。關閉他們的窗戶，並最終運行它。檢查一下，你會驚訝什麼表鎖可以做你的應用程序。

我這樣說是因爲你說這個問題是間歇性的。它來來去去。我懷疑一個表鎖。無論是應用程序執行該操作，還是由另一個用戶對數據庫執行查詢。如果它不是另一個用戶，那麼請檢查以確保您的應用程序每次使用時都關閉與數據庫的連接。

來源

2009-06-24 14:49:53 Randall

也許有一些代碼虎視眈眈不小心設置爲一個非常小的值連接或命令的超時。
也許程序確實偶爾需要運行一段時間，例如，如果服務器正在做其他事情或統計數據已過期
您可以使用事件探查器捕獲超時情況嗎？如果是這樣，proc實際上需要很長時間才能執行？

如上所述here SET NO_BROWSETABLE ON類似於在選擇中使用FOR BROWSE。我想這是ado自動生成的，當它認爲你可能想更新記錄集。你可以設置Recordset的一個屬性來阻止正在發佈的內容，但這似乎不太可能是問題所在。

來源

2009-05-22 18:15:03 Rory

存儲過程超時 - 但從SSMS運行時很好

回答

相關問題