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