>>>
>>>You can index the R/O cursor like this, and then Use it Again - the .cdx should be usable, and should vanish when you close them. Didn't check this out, though.
>>
>>I've always found that you can only put ONE tag on the R/O cursor. The second will give you an error about the fact that it is R/O and fail. Re-opening it again and THEN adding the tags works, but the temporary file for the CDX does not automaticaly get removed.
>
>Here we go again. Yes, only ONE STRUCTURAL index tag - but if it's in a different file than the default same-filename-cdx-extension, then it's not structural and may contain as many tags as you like. Though, this behavior does confuse me - why does it allow creation of this one tag. Existence of a structural index is marked by setting the 0th bit of 29th byte in table's header - and since this works
>
>This works:
>
>sele * from mytable into curs rdonly
>dx=sys(3)
>inde on field1 tag f1 of (dx)
>inde on field2 tag f2 of (dx)
>inde on field3 tag f3 of (dx)
>sele 0
>use dbf("rdonly") again alias rdwrite
>set orde to 2
>browse
>
>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...