>>Too bad you spoiled the game, I wanted JVP to come up with this.
>
>Sorry....I was busy judging oral arguments in court today... Nonetheless, isn't the important thing that you attempted to pit Fox against SQL - and you failed miserably in your point?


>>However, there is something to say about such solution:
>>
>>1. It is not SQL - ANSI 92 compliant.

>So.... you did not make that a requirement.... And, I don't think your solution was fully ansi sql 92 compliant either...

The comparison is SQL against xBase (or record oriented approaches).
My solution is 100% xBase compliant

>>2. If you don't use SQL 2000 or up, you're screwed.

>So..... This is like saying your can kick a person's butt because you started taking kung-fu. They end up kicking your butt and then you complain because they did not attack you rht right way.

Point is that this discussion becomes too narrow in comparing VFP and SQL Server (2000?). For a complete overview you need to compare record oriented with set oriented (xBase vs SQL in this case).

>3. It still is using a SQL SELECT statement for each and every node. Since the nature of a SQL command and its seperation from the interal database scheme (indexes) it is likely to be far slower that the SEEK() solution in VFP.

>Excuse me - you just stated that Rod's solution above was not ansi sql 02 compliant. Where is the seek function denoted in the standard? Also, is HIGHLY suspect that SQL would be slower here....

The seek is a standard xBase command.

>Second, how about the second part of the challenge ? No, please don't answer, I'd like to see if JVP can come up with the solution.

>Sorry Walter....but you just got your butt royally handed to you on the first - no need to entertain more of the same.

You can´t because you don´t have the guts. You´re playing chicken...

>You made the same mistake as Mike Hellend here...

You´re making the same mistake as alway´s: You don´t have a clue about what you´re talking about !!

Walter,