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

I don't think that Jim's point is that he can guarentee that a filtered view can/will be used by a given query; more to the point, he codes so that it doesn't matter which way the cursor is implemented. The idea is to understand what the cursor is intended to do, and how it is intended to be used. If you're dealing with the result of a read-only query on a set, as opposed to a record-oriented, basis, it really doesn't matter how it has been presented. if you're still dealing with cursors procedurally, then filtered cursors are a bad thing, and you can add NOFILTER to the query to make it clear to VFP that you require a distinct seperation of the data from the underlying table.

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

Because of the data that must be moved over the wire to make the cursor available. Using NOFILTER means that the cursor must e extracted and created independant of the base table it has been created from. In a local or LAN environment, this may not be a significant number, but with apps distributed across a WAN, copying data ahead of time has a cost, and if the data only needs to be read, there's a more noticable enhancement of query performance. A delay that's immeasurable on a 100Mbps Fast EtherNet may be significant on a 56Kbps WAN link.

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

This is true of many things in VFP. How many people get 'burned' because of weak data typing in VFP? I'm sure that forcing us to declare and use strongly typed data would avoid a lot of "Operator/operand type mismatch" errors at runtime, because they could be caught by the compiler before the app crawled out the door. It'd make creating structures less painful because the exact nature of data representation would be clearer at compile time, and we wouldn't have to go through the name table resolution of variables to figure out the size and relative locations of things. OTOH, the things we'd have to give up to convert to strong data typing make this an unattractive alternative, for me at least. YMMV. I'd rather have the things that we gain from weak data typing, like on-the-fly creation of undeclared variables...