>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.
>
>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

Jim,

I respectfully disagree with your comment. I ahve code out there that is acceptable in speed directly because it allows filter result sets form sql. Of course I have always viewed SQL as a data fetching command, and never expected it to create anything other than a result set that I would then manipulate so I never encountered any problem with filtered result sets.

Changing this behavior would result in some queries that run in subsecond time to take alot longer to run. In large systems this could become a show stopper. VFP's fame is SPEED, and doing anything that breaks the speed of data processing, IMHO, is a mistake. Especially if there is already a way to get the same result.