Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 12: Stored Procedures
There are a whole host of commands available to Intellisense, but you’ll find that most of these are not
actually available when debugging.
Using the Debugger Once It’s Started
406
Now that we have the preliminaries out of the way and the debugger window up, we’re ready to start
walking through our code. If you were walking through some of the descriptions before, stop the debugger
and restart it so we’re in the same place.
The first executable line of our sproc is a bit deceptive — it is the DELCARE statement for @WorkingIn.
Normally variable declarations are not considered executable, but, in this case, we are initializing the
variable as part of the declaration, so the initialization code is seen by the debugger. You should notice
that none of our variables has yet been set (the initialization code will be next to run, but has not actually
executed yet). Step forward (using the menu choice, the tool tip, or simply press F11) and you should see
(via the Locals window) @WorkingIn get initialized to our value of 5 — @WorkingOut is not initialized
as part of the declaration.
Use the Step Into key one more time. We enter into our first execution of the spTriangular stored procedure
and land at the first executable line in the sproc — our IF statement.
Since the value of @ValueIn is indeed not equal to 1, we step into the BEGIN...END block specified by
our IF statement. Specifically, we move to our SELECT statement that initializes the @InWorking parameter
for this particular execution of the procedure. As we’ll see later, if the value of @ValueIn had indeed
been one, we would have immediately dropped down to our ELSE statement.
Again, step forward one line by pressing F11, or using the Step Into icon or menu choice, until just before
you enter the next instance of spTriangular.
Pay particular attention to the value of @InWorking in the Locals window. Notice that it changed to the
correct value (@ValueIn is currently 5, so 5–1 is 4) as set by our SELECT statement. Also notice that our
Call Stack window has only the current instance of our sproc in it (plus the current statement) — since
we haven’t stepped down into our nested versions of the sproc yet, we only see one instance.
Now go ahead and step into our next statement. Since this is the execution of a sproc, we’re going to see
a number of different things change in the debugger. Notice that it appears that our arrow that indicates
the current statement jumped back up to the IF statement. Why? Well, this is a new instance of what is
otherwise the same sproc. We can tell this based on our Call Stack window — notice that it now has two
instances of our sproc listed. The one at the top (with the yellow arrow) is the current instance, and the
one with the red breakpoint dot is a parent instance that is now waiting for something further up in the
call stack. Notice also that the @ValueIn parameter has the value of 4 — that is the value we passed in
from the outer instance of the sproc.
If you want to see the value of variables in the scope of the outer instance of the sproc, just double-click
on that instance’s line in the Call Stack window (the one with the green arrow) and you’ll see several
things changed in our debugging windows.
There are two things to notice here. First, the values of our variables have changed back to those in the
scope of the outer (and currently selected) instance of the sproc. Second, the icon for our current execution