>>You're right about one thing: the (dx+".cdx") index file doesn't get automatically erased when the cursor is closed IF the first cursor was a filter. If it was created with NOFILTER, it doesn't need to be erased - it vanishes by itself. VFP seems to erase automatically only the first index file, i.e. what you get with cdx(1), and for filtered cursors it's the underlying table's structural .cdx; for non-filtered cursors, this new index is not cdx(2), but cdx(1), and it gets regularly erased when closing.
>>
>>At least, I have finally taken my time to check this :)
>
>I'll have to check out if the NOFILTER removes a structural CDX for more than one tag on a SQL select cursor once it's made R/W. I had always been adding the dummy field or using a WHERE .t. to force the non-filtered version. Haven't made the time to go back and change the old code. If it aint broke, don't fix it.
>
>I just tried it, but neither a WHERE .t. or using a NOFILTER left any residual .TMP files behind on a SQL cursor made R/W with more than one structural tag. Maybe this was something fixed in 5.0a? I'll have to investigate this further...

Well, it automatically deletes the cdx(1), i.e. the first index _file_ (which can contain many tags), unless it belongs to the underlying table (this is the case with a filtered-view cursor).

WHERE clause doesn't help for creating a no-filter cursor; on the contrary, if it returns a small recordset (in case of a real WHERE, not WHERE .t.), you are more likely to get a filter, because its memory footprint is small and there's no need to go to disk for it. Adding a dummy field should give you a no-filter, which then doesn't have a .cdx file, and doesn't borrow one from the underlying table.

If we continue like this, we'll become experts on the matter :)