>However certain problems are less easy to describe in SET ORIENTED DML and really call for a RECORD ORIENTED approach. In specific cases a RECORD ORIENTED approach is an order of magnitude faster than a SET ORIENTED one.

>What's an example of one?

Just read my message again. The file system is an example of a record oriented storage system.

>Have you looked at the new recursive query capability in SQL 2005 for working with hierarchical data?

Yep, I did and I know (we did talk about that earlier). But that is not what I mean. Getting hierarchical data in a SET ORIENTED way is surely possible but that is not the essense of the ISSUE. Some problems are very record oriented in their nature and are best helped with a record oriented approach, some are SET ORIENTED and for most problems, it does not make any (significant) difference.

Again, tell me why we still don't have a file system based on a database?? It surely would speed up random searches ??

There are all kinds of grey areas in between. Solving problems that are hierarchical and nested in nature are best helped with a record oriented approach rather than a SET ORIENTED though one would not exclude the other per se.

Also when it comes to handling sequences (SET ORDER TO) and making calculations in order to dermine something on record level calls for record oriented approaches. Else you've got to download the whole set and do the aftermath otherwise.

Smalll example: A client has multiple invoices. Determine the invoice that exceeded the cumulative balance of $1000. In VFP:

SEEK nDebtor
nDebt = 0 
SCAN WHILE Debtor = nDebtor AND nDebt < 1000
   nDebt = nDebt + DebtAmt
ENDSCAN
** You're at the exceeding invoice

Please post your solution in SQL: