Jim, Fred and Christof,

First let me say that the "fast" applications that you worry about wouldn't "break", though you speculate that they might slow down to the point of unuseability.

What is still unclear to me is just how do you guarantee, in suchj apps, that a filtered result will be provided??? I can see how one can take steps to gaurantee a real cursor, but the opposite eludes me. Perhaps I've missed something??

In addition, if (one of) the determinants of filtered vs cursor is the size of the result set, then is it not possible that the apps in question typically work with small results sets? *IF* this is the case, then why would a cursor present a speed difference of any substance???

I'm betting that, for the few who feel that there is some advantage to filtered results sets there are factorial more who get burned by them. It still also comes down to a fundamental problem when any command in any language can present two differing results without 'notice' of any kind.

Too many people think that either FP/VFP is too complex or that the FP/VFP products do not operate according to their documentation. This is one example of how this opinion comes about, as is the overall (non)quality of VFP's documentation generally. Those who have toiled in the trenches now have an understanding of VFP after (far too) much trial and tribulation. Such a demand is too much for the average "novice".

regards to all,

Jim N

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