David,

>>You almost did get me, but there is something you overlooked.
>>See my notes below...

>It's nothing I over looked, the posted benchmarks are completely valid.

Yep, they are, but in this way you can't get a valid impression how the tag is an advantage to the optimizer. The tests don't compare.

>Then i came to the conclusion that your query's make a FILTER rather that EXECUTE these query's.

>Yes the test did not compare the difference when setting the NOFILTER option. The VFP6 documentation explicitly warns NOFILTER will slow down the select. The main slowdown is disk I/O writing the explicit cursor to disk.

I certainly agree. The main issue i was trying to prove is that partial optimization doesn't have to slower than full optimization. This couldn't be proved if one test produces other results (a filter table) than the other (a real disk cursor).

>I think you under estimate the time cost of the write. I also doubt there is any way to separate the speed gain from the tag vs the speed loss of the I/O.

Agreed.

>>In practice these type of query's are rare and mostly not wanted.

>This is a rather brash and I think unfounded statement. Queries that VFP can internally filter are not rare and certainly wanted.

From the past we've learned that forgetting the nofilter clause can cause weird behaviour in you app as the result cursor is a filtered table. Finding that the cause is at the filtered table isn't easy to detect. I've more than once been pulling my hair out to discover i couldn't use the table again to make it writable.

If you want a filtered table it may be wise just to:

- USE the table
_ SET a FILTER

This not only more clear to the developer, but it is also faster than the SQL eqivalent.

Walter,