我的大多數SP可以通過手動輸入的數據簡單地執行（並測試）。這效果很好，使用簡單的PRINT語句可以讓我「調試」。您最喜歡調試MS SQL存儲過程的方法是什麼？
然而，存在涉及多於一個存儲過程並且找到有效數據輸入的情況是乏味的。從我的網絡應用程序中觸發事件更容易。
我對探查器有一點經驗，但我還沒有找到一種方法來探索我的存儲過程中逐行進行的操作。
你的方法是什麼？
謝謝，一如既往。
注：我假設使用SQL Server 2005+
Profiler非常方便，只需添加SP：StmtStarting事件，並通過設置SPID = xxx將活動過濾到您的過程。一旦你建立起來了，看看發生了什麼很容易。
的您可以在調試器實際上連接到您的SQL Server :) - 來自VS，給你已經配置了您的SQL Server上。
查看此鏈接瞭解更多信息，請注意，您可以設置折點:) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1。
檢查此鏈接爲一個更一般的集合信息的：http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx
更新：關於「然而，有一個以上的存儲過程參與並找到有效的數據輸入繁瑣的情況下，它很容易。從我的網絡應用程序中觸發事件。「
我建議你設置集成測試，重點是與這些過程交互的具體方法。如果程序是由網絡應用程序驅動的，那麼您可以隨時獲得可以運行的有效測試+輸入。如果有多個與程序交互的應用程序，我會考慮單元測試程序。
我更喜歡使用存儲過程進行數據集檢索，並在應用程序端執行任何複雜的「工作」。因爲你是正確的，所以試圖「調試」使用嵌套存儲過程的多層次，遊標循環，臨時表的內部情況是非常困難的。
也就是說，MS KB 316549描述瞭如何使用visual studio來調試存儲過程。
根據這篇文章，有一些限制以這種方式來調試：
編輯：很顯然，如果你是使這個存儲過程的人，那麼就不要讓它「許多層次，光標循環，用臨時表，並嵌套」。然而，作爲DBA的角色，這幾乎是我每天從應用程序開發人員遇到的。
只要不知道有效輸入是什麼，您需要測試大範圍的輸入，包括特別無效的輸入。在編寫你的proc之前，你應該定義你的測試用例。然後，每當有人改變複雜的過程時，您都有可重複的測試集運行。
我的團隊按規則使用SP作爲我們與數據庫的接口;我們這樣做的方式是應用程序用戶只能執行SP（使用我們的命名約定）。
我們使用的一個最佳實踐很適用，即某些測試腳本包含在SP註釋中，並且必須在每次修改SP或新SP開發時執行。
您應該始終儘可能徹底地測試SP，而不涉及任何應用程序層（例如通過Management Studio）。
這招是非常方便的：
確保你進入在VS2005/2008年，當它遇到一個嵌套函數主存儲的過程，打F11（踏入）在進入.. 。繼續調試...從調試菜單中不是很明顯。
我寧願不去調試，而是使用測試驅動開發，這幾乎消除了調試的需要。
數據庫開發人員可能會以與您描述存儲過程非常相似的方式查看應用程序代碼。 – JohnW 2009-03-05 17:32:55
如果你認爲這是可怕的寫作，那麼確定它會很難處理。對於C＃代碼，我會說完全一樣的東西 - 如果開發人員編寫垃圾，你會得到垃圾。 – 2009-03-05 17:51:37
我永遠不會考慮使用「許多分層的，遊標循環，臨時表使用多層嵌套存儲過程。」幾乎總是有更好的方式來做生意。我認爲JohnW所做的一點是，如果你確實做了這樣的事情，那麼根據數據庫人員的定義就會很糟糕。 – HLGEM 2009-03-05 18:01:26