Hi Bob,

>Well, you can't compare the SELECT to a SEEK, you are correct...
>
>SEEK works on an already open table with an existing index set. So, many of the records are buffered already, and perhaps the index is too. The closest comparison you might be able to get to was from a fresh reboot compare...

>USE Table
>SET INDEX TO
>SEEK

Well this is not fare either. If comparing the SQL - Server solution with the VFP solution, the SQL-server database is already open and probably a fair amount of the database is buffered also, esspecially when doing such tests repeatedly.

With VFP, you'll have to open at least two files on the OS level: The DBF, the CDX and possibly the FPT. This is where the DBF database implementation differs significantly from a SQL server database.

>SELECT pk FROM table where pk=1

>Even that isn't a true test, cause the select has to be sent to the back end, and the result has to be returned... this is cause SEEK and SELECT don't really do the same think...

In Rod's example of T-SQL the result was not send back to the client but stored in a viarable which was used in a next SQL SELECT statement to find its parent. This process is all happening on the server and therefore is rather quick. However, if you're looking for a pure (ANSI92) solution, you don't have many other options than indeed downloading the result set to the client, get the personid and use that as a parameter in a next SQL statement. This is exactly the reason why I made the statement that SQL is terrible is solving hierarchical problems.

>SEEK sets the current record to a record that matches the seek value in the table.

>SELECT locates the correct record, creats a result set and returns it.

Indeed, you're correct. Due to this nature the SEEK solution should be far faster in any case.

Walter,