View the article

Combine it with sql2k5 and you can do nifty things like populating the next n levels of nodes in the current tree, with just a single query :). That would work something like:

WITH NestedCategories (CategoryID, ParentCategoryID, [Name], Depth) AS
(
  SELECT c.CategoryID, c.ParentCategoryID, c.[Name], 0 as Depth
  FROM Category c
  WHERE c.ParentCategoryID = @RootCategoryID
  UNION ALL
  SELECT c.CategoryID, c.ParentCategoryID, c.[Name], nc.Depth + 1
  FROM Category c
  INNER JOIN NestedCategories nc ON (c.ParentCategoryID = nc.CategoryID)
)
SELECT * FROM NestedCategories WHERE Depth <= @Depth

Cool stuff joteke.

SQL2005 improved T-SQL is much better than SQL2k/7, makes managing hierarchical data easier, but the task is still a lot of work. Getting data out for display is the easy part, the article "Let’s assume we have TreeViewSampleDB database with the SampleCategories table as follows...", organizing data with tree-path, "1.2.5", getting the correct path data into the table, and also able to update the tree structure, are hard to do. 

My portal site tabs table has a tree-path column for data like "1.2.5", the tree structure can be changed to allow sitemap changes, just like moving file folders in Windows Explorer. The SQL code is complex, UDF, stored procedures, and triggers, all used. It would be difficult for me to explain the code, even I wrote it. Managing hierarchical data in SQL is tricky, but very useful topic, really need more discussion, hope the author of that article will write a follow-on, about how to get the path data in, and update it. 
    

Thanks Jeff, I'll consider that.

I'm not sure if these help you exactly (depends what you have for dealing with the hierarchy dyanmically), but I have a few related blog posts

http://aspadvice.com/blogs/joteke/archive/2005/10/20/13321.aspx
http://aspadvice.com/blogs/joteke/archive/2005/05/19/2331.aspx

And they might get follow-up with the subject you mentioned, faster than the article.