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

Chapter 12: Stored Procedures
I’d love to say there’s some great workaround to this, but, unless you can somehow segment your recursive
calls (run it 32 levels deep, then come all the way back out of the call stack, then run down it again),
you’re pretty much out of luck. Just keep in mind that most recursive functions can be rewritten to be a
more standard looping construct — which doesn’t have any hard limit. Be sure you can’t use a loop
before you force yourself into recursion.
Debugging
Long ago and far away (SQL Server 2000), the Management Studio had real live debugging tools. They
were a little clunky, in the sense that they really only worked around stored procedures (there wasn’t a way
to debug just a script, and debugging triggers required you to create a sproc that would fire the trigger),
but, with some work-arounds here and there, we had the long-sought-after debugger. SQL Server 2005
came along and removed all debugging functionalityfrom the Management Studio (it was in the product,
but you had to use the Visual Studio installation that is part of the Business Intelligence Development
Studio in order to get at it — not very handy in any case, but nonexistent if you didn’t install BIDS for
some reason). I’m happy to say that debugging is back in the Management Studio, and it’s better
than ever!
Starting the Debugger
Unlike previous versions, the debugger in SQL Server 2008 is pretty easy to find. Much of using the
debugger works as it does in VB or C# — probably like most modern debuggers, for that matter. Simply
choose the Debug menu (available when a query window is active). You can then choose from options to
get things started: Start Debugging (Alt+F5) or Step Into (F11).
Let’s do a little bit of setup to show the debugger in action, both in a standard script and in a stored procedure
scenario. To do this, we’ll use the script we were just working with in the previous section (to exercise
the spTriangular stored procedure we also created earlier in the chapter). The script looked like this:
DECLARE @WorkingOut int;
DECLARE @WorkingIn int = 5;
EXEC spTriangular @WorkingIn, @WorkingOut OUTPUT;
PRINT CAST(@WorkingIn AS varchar) + ‘ Triangular is ‘
+ CAST(@WorkingOut AS varchar);`
With this script as the active query window, let’s start a debugging run with the Step Into option (choose
it from the Debug menu or simply press F11).
Parts of the Debugger
402
Several things are worth noticing when the Debugger window first comes up:
❑ The yellow arrow on the left (Shown in Figure 12-2) indicates the current execution line — this is
the next line of code that will be executed if we do a “go” or we start stepping through the code.