>>
>>This phantom is around since 2.0 or so - most of the time you can index a cursor any way you like, but sometimes you just can't.
>>
>>The way around is to use a nondefault name for the .cdx file:
>>
>>

cCdx=[ your favorite temp file name generator here]
>>Index on cThis+cThat tag Name1 <b>of (cCdx)</b>

>>
>>And that's it. The index will get deleted when the cursor is closed, at least now that I tried (in VFP7) - I seem to recall this was a problem in some previous versions.
>
>Related to what you're saying, I have a theory about why this is happening. (I may be way off base here...) When you create an index on a cursor, it is actually creating a temporary file in your work directory with a unique name assigned by VFP. If you are working on a large application that uses alot of indexed cursors, and the work directory starts to get cluttered with files that never got cleared out because of crashes and what have you, I could see this problem happening on an intermittent basis. It's best to define a tmpfiles directory and make sure it's clean every once in a while.

The regular index on a cursor has forceext(dbf('cursoralias'),'cdx') for a name. There seemed to be some regularity as to which cursors needed this workaround, namely it would be the same cursors each time, in maybe two or three places around the app, while the others indexed regularly. Still, the technique has yet another good side (apart from working each time without a glitch), and that's the ability to create more than one tag on a read-only cursor.

As for the cleanup of the junkyard, you're right - independently from this subject. The rule-of-thumb I've established from experience, and found a few older colleagues who did the same, is to delete any of these files if they are more than two days old. That's the empiric measure of when there's no more chance that something may still be using them.