I think that is pretty clear on what will happen then. Rushmore
is a great technology, it just has one itsy bitsy gotcha that NOFILTER
is a workaround for. And maybe while the fox team is in there anyway
adding the READWRITE clause to the rushmore engine for VFP7, they can
finally address this and get the language command to work the same regardless of the optimation method.

>Did you do the same tests with SET OPTIMIZE ON and OFF?
>
>Vlad
>
>>Rushmore is the genie that makes them. If the engine decides that a filtered result set will be the quickest way to go, then it returns them.
>>
>>I discovered this when I added an index tag on DELETED() (which spawned the other part of this thread), and suddenly I received 'filtered result sets' whereas before the tag I received a NOFILTER version.
>>
>>The same SQL statement was used for both versions, adding the DELETED() tag returned filtered result sets, deleting it returned NOFILTER versions.
>>
>>And of course, several commands that had been working with NOFILTER stopped working when the DELETED() tag was added.
>>
>>That's how we all go into this mess ;)
>>
>>
>>>I haven't read all messages in this thread. What does Rushmore have to do with filtered cursors?
>>>
>>>Vlad
>>>
>>>>Just a quick point, NOFILTER is an OK workaround for SELECT..WHERE, as you
>>>>say you will always get a file. But SELECT * (no where), the NOFILTER has a negative effect since it copied the entire file, when it this case, the rushmore version works OK...