What are good methodologies for creating sprocs that reduce the pain of debugging? And what tools are out there for debugging stored procedures?
Perhaps most importantly, what are indications to look out for that errors are happening in a sproc and not in the code? I hope I'm not all over the board too terribly bad here. Votes for answers to any of the above. Thanks.
For what it's worth, I work in a .NET environment, SQL servers.
To debugging SP, go to database->Programmability->Stored Procedures-> right click the procedure you want to debug->select Debug Procedure.
In Object Explorer, connect to an instance of the SQL Server Database Engine, expand that instance, and then expand Databases. Expand the database that you want, expand Programmability, and then expand Stored Procedures. Right-click the user-defined stored procedure that you want and select Execute Stored Procedure.
You can open the SQL Server Debugger through a right click in the Schema Browser on Stored Procedures or User Defined Functions and selecting Debug from the popup menu.
One technique I use in stored procedures to make them easier to debug (without IDE or debuggers) for SQL Server 2005 procedures:
I add an input parameter named @Debug = 0 (defaulted to 0 = off) at the end of the parameter list for the procedure.
I then add if (@Debug = 1) print '...';
statements in the code at key junctures to display any useful internal values etc.
Yes, it's "old school" and debuggers that let you "walk the code" are great - but this works for anyone from any SQL tool (including anyone debugging without your same IDE).
Ron
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With