>Fred,
>
>My resultset was about 16.000 records and not the whole expression was rushmore optimizable.

>I've seen result sets of ~ 40K records in less than 1 second. They do require full optimization for those kinds of speeds.

Sure it depends on lot of things (network, server, Processor, memory, width and structure of the table) but such response times occur almost always if the query or a part of the query has ran before. Another trap is that VFP can simply set a filter on the original table, so it takes no time to run the query.

VFP just keeps the former resultset in memory (or in the temp dir) and uses it when the optimizer concludes that no changes are written to the table.

>You're arguments about the DELETED tag not making a difference when the rest of the query is not optimized just don't tell us anything.

Well, it does. If a index on deleted makes no differece in a partual optimized query, how can it benefit within a fully optimized table ?

Well, i know some cases in SQL-server where the resultset is build by only the index information (without touching the original table at all) but this kind query's are rare and to my best knowledge VFP is not using this technique .

>If the DELETED tag made no difference when everthing else was optimized, then you'd have something. I've seen many instances where not having a tag on DELETED() made a hugh difference in time, like queries that took 2-3 minutes without the tag, and less than 3 seconds with it. My vote is for the tag.

I did just test it with full optimization and like i said before it does not make any difference. The cases you've are most likely due some other problems (maybe have large amounts of deleted record in the resultset or joining two or more table with substatial amounts of deleted records.)

Just my fl 0.02

Walter