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

Chapter 13: User-Defined Functions
420
Again, at first glance, this might appear to give us what we want:
EmployeeID JobTitle LastName FirstName
----------- ------------------------------ -------------------- --------------------
5 VP of Engineering Olsen Ken
6 VP of Professional Services Cross Gary
7 VP of Security Lebowski Jeff
(3 row(s) affected)
But, in reality, we have a bit of a problem here. At issue is that we want all of the people in Karla’s reporting
chain — not just those who report to Karla directly, but those who report to people who report to Karla,
and so on. You see that if you look at all the records in our newly created Employee2 table, you’ll find a
number of employees who report to Ken Olsen, but they don’t appear in the results of this query.
OK, so some of the quicker or more experienced among you may now be saying something like, “Hey, no
problem! I’ll just join back to the Employee2 table one more time and get the next level of reports!”
You could probably make this work for such a small data set, or for any situation where the number of
levels of your hierarchy is fixed — but what if the number of hierarchy levels isn’t fixed? What if people
are reporting to Robert Cheechov, and still others report to people under Robert Cheechov — it could go
on virtually forever. Now what? Glad you asked. . . .
What we really need is a function that will return all the levels of the hierarchy below whatever
EmployeeID (and, therefore, ManagerID) we provide — we need a tree. To do this, we have a classic
example of the need for recursion. A block of code is said to recurse any time it calls itself. We saw an
example of this in the previous chapter with our spTriangular stored procedure. Let’s think about this
scenario for a moment:
1. We need to figure out all the people who report to the manager that we want.
2. For each person in Step 1, we need to know who reports to him or her.
3. Repeat Step 2 until there are no more subordinates.
This is recursion all the way. What this means is that we’re going to need several statements to make our
function work: some statements to figure out the current level and at least one more to call the same
function again to get the next lowest level.
Keep in mind that UDFs are going to have the same recursion limits that sprocs had — that is, you can
only go to 32 levels of recursion, so, if you have a chance of running into this limit, you’ll want to get
creative in your code to avoid errors.
Let’s put it together. Notice the couple of changes in the declaration of our function. This time, we need
to associate a name with the return value (in this case, @Reports) — this is required any time you’re
using multiple statements to generate your result. Also, we have to define the table that we will be
returning — this allows SQL Server to validate whatever we try to insert into that table before it is
returned to the calling routine.
CREATE FUNCTION dbo.fnGetReports
(@EmployeeID AS int)
RETURNS @Reports TABLE