>>In my case, it was a treeview, and the recursive approach was used while building the key. Then when the treeview needed to be built, the table was ordered using this key, and the treeview was built within a single linear pass through the records. The main (and practically only) reason for this was speed: the table changed very rarely, but the treeview had to be built many times. So this was just a way to have the results of the recursion saved and ready. The difference in speed turned out to be quite significant, somewhere to 6:1 for 200 records.
>
>Do you think I would obtain the same ratio when working with a cursor? Our cursor is pre-built before creating the treeview object. So, if I have 200 records in it, I'll have 200 records in the treeview. Do you think using linear approach here would make it faster as well?

You have to recurse at least once, and the time it takes is more or less fixed. Now it's the matter of reusing the results - if the cursor is killed immediately after use, there's no point.

What I found as a waste of time in my case was the logic "for each record, do an SQL to check for its children", which was unnecessarily slow, because it meant one SQL select for literally each record. The "if seek-scan while" logic worked much faster, and since the result was very reusable (a report dictionary, which changed only when a report was added, or the organizational structure within an institution, which changed only a few times a year) this approach was good. And it never had to go too deep - four levels at most.

If your case is the messages in the thread, that may go dozens of levels deep, and you'd pretty soon hit the limit on the length of the key, and the solution may prove impractical. You're better of with recursing on "if seek- scan while", with just keeping record pointers in local variables. I'm currently writing an utility like that, and it's blazingly fast.