Hi Fred,

>>SNIP
>>
>>Christof,
>>
>>There have been enough reports here to convince me that VFP *will* vary in its choice of filtered vs cursor in the same SQL in the same application.
>>
>
>If you do a SELECT * FROM sometable INTO CURSOR xyz, I've never seen it do ANYTHING but a filtered result set. Only if you add some kind of other field, join another table, not match an index key, WHERE .t., NOFILTER, have I seen otherwise. I would not have a problem with a SET SQLFILTER ON/OFF or some other kind of setting to control it, but I need the "filtered view" as it currently exists.
>

Christof asked for an example and, unfortunately, I cannot supply one. I have been using NOFILTER since it became available, so maybe that explains something.
But as I say, others here have reported it. Hopefully they may chime in with examples.
By the way, I wonder how you can be **certain** that you always get a filtered result set??? Since your programs would be coded in such a way as to function correctly with a filtered result set, and since a cursor would let the same code function correctly too, How can you be so certain???


Regards,

Jim N

>>
>>I would agree that an app which consistently gets a filtered result set could "break" if a cursor were suddenly provided and the app was running on a very low disk space system. But I am still not sure that a filtered set can be *guaranteed*. Is there something in the VFP documentation regarding this?
>>
>>Cheers,
>>
>>Jim N
>>
>>>
>>>VFP follows certain rules when it creates a filtered result cursor. It won't create a filterd cursor one time, and a physical cursor another time.
>>>
>>>>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?
>>>
>>>Why should they work on small result sets?
>>>
>>>Christof