>Hi Christof,
>
>Just because it has been that way for a long time is *not* reason enough to avoid changing this. . .
>
>There should be absolutely *NO* problem changing the internals of VFP to simply *NEVER* (repeat: NEVER) create a 'filtered result' in a SQL statement! No existing program should break as a result of this.

I'd have to agree with JB on this one. I've got LOTS of code that's very dependant on that "filtered view" comming back instantly. Just try using a TOP n in a SELECT statement and see the difference in how long it takes to execute on a table with a 50K or more records. Please, there are uses for the beast, don't tame it!


>
>How many other FP/VFP commands can you name that will produce one or another outcome without notice of any kind to the user???
>
>And here I take the opportunity to point out that, even though there is now a NOFILTER clause the documentation hardly makes it clear what the actual effect is.
>
>regards,
>
>Jim N
>
>
>BIG SNIP
>>
>>Yeah, but why should the VFP team add just another feature and change the behavior how certain things work, just because many developer forget to add NOFILTER to the SELECT statement. After all, this behavior really goes back to FP 2.5 and probably even further back.
>>
>>Christof