>Hi Fred,
>
>In this particular case I doubt that it would have any adverse effect on existing code *because*, even without a NOFILTER clause it can still create a cursor/table anyway. The NOFILTER is just 'insurance' that it will not use a filter.
>
>Cheers,
>
>Jim N

Hi Jim,

Possibly so, but I always used to do a WHERE .T. to force the issue (when absolutely needed) anyways. Though it is tough to beat the speed of one of those "filtered view" queries!


>
>>>Hi Walter,
>>>
>>>... And I would bet that if the VFP team eliminated them (ie made NOFILTER the internal default) then no one would even notice and there would be no problems from that release onward.
>>>
>>>Cheers,
>>>
>>>Jim N
>>>
>>
>>I seriously doubt that:
>>A) they will change it
>>B) if they did, that it wouldn't have an adverse reaction to a lot of people's code
>>
>>It really is extremely difficult to change anything to be the opposite way, no matter how "right" the new way is. It will always impact somebody! But I do agree, it probably SHOULD HAVE BEEN the other way, or to at least have had some sort of setting like SET NOFILTER ON or something like that. At least with a setting, it's your choice to change it!
>>
>>Fred
>>
>>>>Jim,
>>>>
>>>>I agree that this feature is giving a whole lot of trouble. Though some will say it can be used to optimize your application, you can always set a filter: like:
>>>>
>>>>USE TABLE
>>>>SET FILTER TO expr
>>>>
>>>>This filtered tables feature is absolutely of no added value and is the cause of a whole lot of trouble. I would recommend the fox team to switch the default behaviour from filtered to non-filtered resultsets.
>>>>
>>>>Note that the most of use use the SET DELETE ON settings in his/her applications. Since i'm against the use of a DELETED() tag I normally don't experience these resultsets (because fox can't fully optimize the query), but if it can I'll be banging my head against the wall why the program does not work as espected.
>>>>
>>>>Walter,