Don't forget Rod - seek necessarily requires that all data is brought to the client. If you think about it, SQL Select is not only faster - but it is likely to be much faster when you consider that with a seek - everything is done at the client. With SQL, a request to the server has to be made, the server has to process the request, and the results have to be returned.

It reminds of a certain chap someplace else who compared inserting and deleting 700K rows in Fox and SQL Server. I believe his stats where something like 15 sec's for Fox and 80 sec's for SQL Server. On the basis of that - they guy concluded that Fox is better. Of course, what the "chap" failed to recognize was that for every insert - there was a tx log entry. And for every delete - there was a tx log entry. And on the deletes, I suppose there was some overhead in trying to reclaim space. Of course, there is the updating of indexes to contend with. I believe in the guy's tests - he never bothered to do a pack. Rather, he just logically deleted the records. I suspect that if we just zapped the dbf and truncated the sql server table - the number would have been much more closer. SQL Server might have overtaken Fox for all we know.

People that attempt to compare file-based systems to server-based systems at face value simply do not understand the inherent differences between the two systems.

< JVP >




>Actually,
> Walters point is that SEEK performs faster than SQL SELECT. Which in the example I provied I disagree with. SQL Select based on a key will perform with speed similar to seek.
>
>Rodman