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

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