IMHO, it gives Fox & Rushmore reputation of sophisticated technology. I think Erik is 100% correct in his reply: a developer should be aware of what he/she is doing with data and apply different ways in appropriate form.

>The key is 'as long as you know what is happening'. I don't think anyone disagrees that speeding performance is a bad thing, but when the engine *might* return different result types based on rushmore, it gives fox the reputation that it is not stable.
>
>When we all know it is stable, 'as long as you know what is happening' ;)
>
>
>
>
>
>>They are not a cursoe IMHO, as long as you know what is happening. If your work requires that you have a physical table on disk, then use the NOFILTER clause.
>>
>>This behavior was designed to speed performance, and in cases where the result set is large, it very often increases performance dramatically, because the result set is not being rewritten to another file.
>>
>>
>>>Hi Craig,
>>>
>>>These damned 'filtered results sets' (or whatever they are popularly called) are a CURSE. They cause only trouble and give virtually no advantage. It would be wise of MS to ELIMINATE that "feature".
>>>
>>>Cheers,
>>>
>>>Jim N
>>>
>>>>>If you have a large table, and perform a SQL Select, Rushmore might USE AGAIN the table with a filter in effect. The BIG problem with this (which I think is a bug), is that the entire file is still available as are the records of original files. Rushmore should always return the same type of cursor regardless of what it had to do. The bug is also in the GO command, which disregards the rushmore filtered file and actually GO's to the record in the parent file, not the query result!
>>>>>
>>>>>For example:
>>>>>
>>>>>SELECT * FROM TESTFILE WHERE KEYFIELD = 1 && Keyfield is indexed
>>>>>* Should return 1 record
>>>>>GO 1
>>>>>? KEYFIELD
>>>>>GO 2
>>>>>? KEYFIELD && prints record 2 keyfield
>>>>>GO 3
>>>>>? KEYFIELD && prints record 3 keyfield
>>>>>
>>>>>Same Code with NOFILTER:
>>>>>SELECT * FROM TESTFILE WHERE KEYFIELD = 1 NOFILTER
>>>>>GO 1
>>>>>? KEYFIELD
>>>>>GO 2 && EOF error
>>>>>GO 3 && EOF error
>>>>
>>>>This is by design, and only happens when you do this type of SELECT (ie. one table, with no calculated fields, etc.). There are ways to get around it. Look at the NOFILTER clause. You can also add a calculated field. Note that when you do a multi-table join, VFP does a USE AGAIN on the tables.