>>>>Hi Sergey,
>>>> Yes, the question is: why is VFP creating an in-memory cursor w/o physical presence on the disk despite the use of NOFILTER in the SQL Select statement. I have a workaround that works, but I'd prefer to be able reliably to create a cursor with a disk presence.
>>>
>>>Hmm, VFP9 help says, for NOFILTER:
>>>
>>>"Including NOFILTER can reduce query performance because it creates a temporary table on disk. When the cursor is closed, the temporary table is deleted from disk."
>>>
>>>I'm wondering if the help is not quite correct - it may be more correct to say that "it creates a conventional VFP cursor, rather than a filtered result set" and, as such, this cursor can be used in further queries (where a filtered result set cannot).
>>>
>>>A VFP cursor may or may not have a disk presence. If you want a guaranteed disk presence, you should probably look at INTO TABLE with a temporary file name generated by SYS( 2015 ) etc. However, in that case you'd need to clean up after yourself when you're finished with it (i.e. delete the temp table).
>>
>>I work a lot with this kind of code, and I have never seen a cursor created with Select .. Nofilter which is not a .real tmp file. AFAIK all cursors, exect filtered tables, are real files. Try

>>Create Cursor test1 (name c(10))
>>Display Status

>>You will see that a .tmp file is created in your tempfiles directory.
>>
>>I am pretty sure the error in this case is caused by something else.
>
>VFP9 help also says, about INTO CURSOR:
>
>"Cursors can exist as a temporary file on the drive or volume specified by SORTWORK." (my emphasis). The "can" means they might exist, not that they always will exist.
>
>In your example above, CREATE CURSOR creates a read/write cursor. My understanding is:
>
>- the clauses NOFILTER and READWRITE both increase the probability that a cursor will have a disk presence
>
>- the greatest chance of not having a disk presence would be where neither NOFILTER nor READWRITE are specified, the result set is small, and VFP has lots of available RAM
>
>Paradoxically, if the machine has lots of RAM available, it may be using some for a write disk cache. In that case, creating a temp file may be extremely fast, so the VFP optimizer may decide it doesn't cost much to do so.
>
>I, too, have done a lot of work with temp cursors and I have definitely seen cases, and had to fix subtle resulting bugs, when .tmp files were not created. Admittedly, the cases I saw were with earlier versions of VFP ( 5 and 6, IIRC ) on older, slower hardware. Some might even have been while running on W98.
>
>This raises another possibility, that maybe during the rewrite/enhancement of the SQL engine in VFP9, that the behaviour for writing temp files was changed.
>
>I haven't read the whole thread, but has anyone mentioned turning off AV if present? Scanning might delay or interfere with creating .tmp files.

I seem to recall that this was actually "officially" changed on urpose in one of the last releases, probably VFP8, so that a .tmp file is now always created except when a filtered table is used instead.