>>>>>

SELECT * FROM mytable WHERE keyvalue = "myvalue" INTO CURSOR myCursor
>>>>>? DBF('myCursor')

>>>>>
>>>>>On my computer I get an unexpected result of: c:\tempfilepath\xxxx.tmp
>>>>>
>>>>>On a co-workder's computer I get the expected result of: c:\path\mytable.dbf
>>>>>
>>>>>
>>>>>
>>>>>Is there some setting or condition which controls whether or not a cursor is created NOFILTER by default?
>>>>>
>>>>>Thanks to all..........Rich
>>>>
>>>>Hi Rich
>>>>
>>>>For me, all the technical details in the world don't really answer the fundamental question:
>>>>
>>>>"Does one EVER want an SQL command to mysteriously turn into a SET FILTER?"
>>>>
>>>>My answer is no. That is not what I call an expected result. If I want SET FILTER, I'll use it specifically. Add NOFILTER always. Yes, even if you have READWRITE. There is no harm in having NOFILTER and READWRITE. There will be harm if you later have to remove the READWRITE and forget the NOFILTER....
>>>
>>>I always add readwrite, since it is more "universal" and makes nofilter redundant.
>>
>>There may be times when you don't want the cursor to be readwrite. :)
>
>Yes, I remember that I needed it once, it was in 1995. :-)

I think you might be right on READWRITE. :)

I can only think of lookup cursors being read only, except that I occasionally want to switch them to readwrite dynamically. It is very nice to see 'NOFILTER' to be reminded that it's in effect.