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

Chapter 12: Stored Procedures
400
@ValueOut int OUTPUT
AS
DECLARE @InWorking int;
DECLARE @OutWorking int;
IF @ValueIn != 1
BEGIN
SELECT @InWorking = @ValueIn - 1;
END
ELSE
BEGIN
END
RETURN;
GO
EXEC spFactorial @InWorking, @OutWorking OUTPUT;
SELECT @ValueOut = @ValueIn * @OutWorking;
SELECT @ValueOut = 1;
So, what we’re doing is accepting a value in (that’s the value we want a factorial of) and providing a
value back out (the factorial value we’ve computed). The surprising part is that our sproc does not, in
one step, do everything it needs to calculate the factorial. Instead, it just takes one number’s worth of the
factorial and then turns around and calls itself. The second call will deal with just one number’s worth
and then again call itself. This can go on and on up to a limit of 32 levels of recursion. Once SQL Server
gets 32 levels deep, it will raise an error and end processing.
Note that any calls into .NET assemblies count as an extra level in your recursion
count, but anything you do within those assemblies does not count against the
recursion limit. While .NET functionality in SQL Server is beyond the scope of this
book, keep in mind that it is a potential way around nesting level issues.
Let’s try out our recursive sproc with a little script:
DECLARE @WorkingOut int;
DECLARE @WorkingIn int;
SELECT @WorkingIn = 5;
EXEC spFactorial @WorkingIn, @WorkingOut OUTPUT;
PRINT CAST(@WorkingIn AS varchar) + ‘ factorial is ‘ + CAST(@WorkingOut AS varchar);
This gets us the expected result of 120:
5 factorial is 120
You can try different values for @WorkingIn and things should work just fine with two rather significant
hitches:
❑ Arithmetic overflow when our factorial grows too large for the int (or even bigint) data type
❑ The 32-level recursion limit