Hi John,

>>>I was not making the argument - I was responding to the argument. No question that Fox + DBF's is flexible. The point I made was that .NET + SQL Server can be just as flexible. Put another way - it cannot be demonstrated that .NET + SQL Server is any less flexible than Fox + DBF's.
>>
>>O.k. You asked for it:
>>
>>Just imagine a famility tree. Query: Find the oldest ancestor of any given person through the male line:
>>
>>VFP
>>

FUNCTION GetUpperMaleAncestor(nPerson)
>>
>>DO WHILE SEEK(nPerson,"FamilyTrees","MaleParent")
>>   nPerson = FamilyTrees.Person
>>ENDDO
>>RETURN nPerson

>>
>>Now retrieve all offspring of this person
>>
>>

FUNCTION RetrieveOffSpring(nPerson)
>>
>>CREATE CURSOR offSpring (Person I)
>>SELECT FamilyTrees
>>SET ORDER TO TAG MaleParent
>>
>>DO GetOffSpring(nPerson)
>>
>>SELECT * FROM FamilyTrees WHERE EXIST (SELECT Person FROM OffSpring) INTO CURSOR Result
>>RETURN
>>
>>*-
>>
>>FUNCTION GetOffSpring(nPerson)
>>LOCAL nRec
>>
>>nRec=RECNO()
>>SEEK nPerson
>>DO WHILE !EOF() AND MaleParent = nPerson
>>    INSERT INTO Offspring (Person)
>>    DO GetOffSpring (Person)
>>    SKIP
>>ENDDO
>>GO nRec
>>RETURN

>>
>>
>>O.K. Your turn to write the SQL example and the ADO.NET implementation (Good luck).

>I don't have a lot of time to deal with this now - but consider this. What you have written above can easily be replicated in T-SQL. That said, I would write a stored proc - and call it in ADO. Big deal....

At what cost. We are comparing the flexibility. This includes how easily a solution can be made. I want to lay-out that in these kind of cases a record oriented approach wins hands downs in terms of efficiency and performance.

>Fact is that SQL DML is terrible in solving hierarchical problems. This is one area where record oriented DMLs like xBase excell and indeed have an advantage over a SQL implementation.

>What are you talking about. I can declare a cursor in SQL - and loop through the results row by row.

You´re talking about iterating through a resultset, however I´m talking about solving hierarchical problems. I´m pointing out that the solution in SQL is slow, and cumbersome.

>What you state here is not supported by the facts. I suggest you check out and learn what can be done in T-SQL.

You insisted to compare dbf styled solutions with SQL. You seem to have a very different definition of SQL. With SQL you imply SQL server. You´re insisting on propetary solutions based on TSQL that is not a part of the ansi SQL definition. You cannot use the same solution for Oracle, Informix, Sybase or whatever ANSI92 compliant database.

>For one thing - T-SQL supports the full ambit of SQL - unike Fox. Be careful about he challenges you lay out - just as you did here. With little effort - they can be met.

At what cost. I dare to say that record oriented solutions might be a way and way faster than the clumsy solutions in TSQL.

Again, You don´t know what you´re talking about when using the word SQL, SQL does certainly not refer to the specific implementation of SQL server 2000 and up.

Water,