>>>>Okay, granted, your design has to be sound (ie. indexing) and the SQL statement has to be optimized...and it depends what you are trying to do...but, I haven't found too many cases where an **optimized** SQL statement has been noticably slower than SEEK and SCAN...I haven't worked with 11,000,000 record tables (at least not in FoxPro), so I can't really comment on that situation...
>>>>
>>>>Joe
>>>
>>>The main thing is not even number of records in a table, but how many records will be retrieved by Select-SQL. Seek will be also more relevant for the case of soft search (SET NEAR ON).
>>
>>
>>Again, every case will be different...but if I use a Select-SQL command, the number of records that are retrieved is the number that I wanted...
>>
>>If I only wanted one record, it goes without saying that I would use a SEEK if the index is available...
>>
>>Take care,
>>Joe
>
>I meant, that sometimes you could expect small number (10-100) records from high-volume table, and let say you want to build sophisticated cursor from these records. This case SEEK could be more relevant especially if you search by part of compound index using SET NEAR ON, i.e. Seek will return .f. anyway, and SQL will be very slow.

Again, every case will be different...

In this case we are not talking about a fully optimized SQL command...

The general rule of SQL over SEEK-SCAN holds true for, I would estimate, >95% of the time...of course, if you prefer SEEK-SCAN, and we are talking about milliseconds, who cares?

Joe