This afternoon, Adam Machanic (blog | twitter) reminded me how the current T-SQL debugger in Management Studio is ineffective. Sure, there are some enhancements coming in Denali (I mentioned them briefly yesterday), but there are some real key elements missing. One of the most glaring omissions is the ability to see the contents of #temp tables and @table variables during a debugging session. For stored procedures that can take a long time to run, it is quite cumbersome to edit the procedure to dump the contents of the #temp table as a resultset, which can obviously interfere with the operation of the procedure (especially if applications currently rely on its interface). As Adam eloquently stated, "All I want right now is a debugger that helps with real challenges. Scalar variables are not enough."
Hear, hear. This is one of the reasons I have yet to step back from my curmudgeony debugging methods: PRINT, RAISERROR, and (since 2005) TRY/CATCH. I don't come from an OOP background, but I do understand why many people value a more formal method of debugging.
So, how can you help? Well, I know some of you do not believe in Connect, but for those that do – this issue of not being able to see into #temp tables and @table variables is covered by no fewer than four Connect items. I am asking that you go and vote for all four of them, because Connect doesn't have a good way for us peons to close duplicates and focus on a single item. (I'd love to pick just one and tell you to vote there, but with my luck, Microsoft will choose a different one to keep alive, if they ever get around to consolidating.)
So please, if you value debugging and you want to see better improvements than just being able to watch scalar variables, vote on these items. And if someone tells you they're going to create a new Connect item in a similar vein, please tell them to search first. Having multiple items covering the same issue just spreads out the votes and makes it less likely that the issue will be tackled. Thanks!