>>>>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
>
>
>It could be slower if you have lots of index tags. The SQL SELECT must examine each index tag to see if
>it can be used to optimize the query. A SET ORDER TO TAG blah, SEEK blahblah could be faster.


Sure, but what kind of difference are we talking now? Milliseconds? And if we are only looking for one record (ie. SEEK), of course you would just use SEEK...I think we originally were talking about retrieving multiple records...

Regardless, as a rule, if you can use an optimized SQL command to retrieve sets of records, you can use it and be sure that it will either be faster (and possibly a lot faster) than SEEK...SCAN, or that it will be a similar speed (ie. the operator won't notice the difference).


Take care,

Joe