“That little green arrow.” or “My code used to work but now I’m getting a debug error.”
3October 15, 2015 by Kenneth Fisher
If you’ve worked with SSMS for any length of time this will look awfully familiar:
SSMS 2008R2
SSMS 2012 +
This little green arrow turns on the Transact-SQL Debugger. I have to wonder how this feature is actually used on purpose. I mean I’m sure people do, I’ve just never met any of them. Probably because the debugger requires sysadmin level permissions. Most sysadmins aren’t writing a lot of code (or at least don’t need the debugger) and most developers that could use the debugger don’t have sysadmin access. What I do get is the occasional person coming up to me and saying “I don’t understand why I’m getting this error? My code used to work!”
And why? You guessed it. They hit that little green arrow. I have to say that little green arrow really seems to confuse people. Probably because in Visual Studio you use the green arrow to “execute” a package (an SSIS package for example). Which sounds a lot like MS messed up and used different symbols to mean the same thing. In reality, however, you are executing that SSIS package in debug mode. So in fact it really is the same thing.
Regardless, the important thing to remember is that in SSMS the ! is execute and the arrow is debug. You want execute.
Thank you for posting this! I’ve always wondered about this arrow 🙂
So is the debug arrow (in SQL server) does the same thing as the debug green arrow in VB?
In what cases that I may need to use it (as I never did so far!) since I never dealt with SSIS packages?
I’m using SQL Server 2008R2 Standard edition.
Glad it helped! I have to admit I’ve never used it myself. If you do start playing with it let me know how it goes 🙂
I am a sysadmin, I develop, and I support about a hundred developers who are not sysadmin on the corporate servers ( but can be a sysadmin on any SQL Server that they run on their own boxes). I debug stored procedure code while I am writing it, but instead of debugging a stored procedure call, I debug the T-SQL batch used within the stored procedure’s definition. If the stored procedure accepts parameters I instead declare them as variables (when I plan on debugging). I set break points, start the debug session, and let the code run. The code will stop running when the breakpoint is hit, and display my variables’ values at the breakpoint. I consider whether the variables values are reasonable at the breakpoint line, and adjust my stored procedure code if values are not what I expect my code to have assigned. More often than not my stored procedure is performing recursion and/or controlling its code flow in a Row By Agonizing Row manner (when I am dragged, kicking and screaming, into writing RBAR code).