>>>>>Although, in almost every situation, SQL commands will be faster than going through a do while loop....
>>>>>
>>>>
>>>>Not true...SQL commands are not necessarily faster. It depends on;
>>>>
>>>>1) The amount of data
>>>>2) Proper indexing
>>>>3) Amount of virtual memory on the PC
>>>>4) How the SQL statement is structured
>>>>
>>>>At a previous job, I had an 11,000,000 record table. SQL came to
>>>>a CRAWL when using this table. SEEK and SCAN were *MUCH* faster.
>>>
>>>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.