This code works (in SQL 2005), by creating a temp table, #DepTree, and inserting dependency relations into it. it starts with the current object in question, and inserts it into #DepTree at level 0. Then it moves into a loop which will continue as long as an insert was made in the body of the loop. It uses the int identity column of #DepTree to do this.
The dependency parsing goes in both directions - it will report all objects dependent on the one in question, and all objects on which it is dependent. That is the use of the DepLevel column. Positive values represent objects on which the starting one depends, whereas negative ones depend on the starting object. You can think of these as parent/child relations in the dependency chain.
Both of the blocks of code that check @DepLevel will process the one row where @DepLevel = 0, but this is the ONLY value that will be checked in both directions. The reason is that we don't want to go up a level, and then check the objects down from there; we would end up in an infinite cycle moving up and down the dependency chain between the first two objects.
Run it by simply replacing the string 'ENTER_YOUR_OBJECT_NAME_HERE' with the object of interest. Your choice is unrestricted by type (you can enter a table, stored procedure, etc.), but when I wrote this I had in mind reporting on the chain of stored procedure calls.
One important note - if a stored procedure references a second stored procedure that did not exist at the time the first one was created, no entry will be made into the sysdepends table, and the dependency chain will thus be broken. Check out the articles Fixing SysDepends and Finding Real Dependencies for an interesting take on this.
