“That little green arrow.” or “My code used to work but now I’m getting a debug error.”

3

October 15, 2015 by Kenneth Fisher

If you’ve worked with SSMS for any length of time this will look awfully familiar:

SSMS 2008R2
SSMS_GreenArrow1

SSMS 2012 +
SSMS_GreenArrow2

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!”

SSMS_GreenArrow3

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.

3 thoughts on ““That little green arrow.” or “My code used to work but now I’m getting a debug error.”

  1. Shayma says:

    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.

  2. Bill says:

    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).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 2,148 other followers

Follow me on Twitter

ToadWorld Pro of the Month November 2013
%d bloggers like this: