>Sergy
>
>As you have heard from MANY others....thanks for your incredibly quick response. I looked at the message and have some questions about WHY it works.
>
>

>IF tnError = 1707
>	* CDX is missing
>	RETRY
>ELSE
>

>
>When error 1707 occurs, does Fox 2.6 generate the error and remove the reference from the table???? That would explain why my second user's attempts would work. And also why this error trap merely retries the USE.

Yes, though (don't remember the details) it may depend on your Set Safety and Set Notify. The reason I don't remember this was because I haven't seen the message for quite a number of years, because my indexing routines have removed the reference from the table, deleted the cdxes, and created new ones automatically. The reference is a 1 in 28th byte of the table header, and gets removed with writing a zero there.

Too bad this approach to indexing doesn't work anymore - it actually can't cut it in DBC environment, where an index is not a matter of one cdx file and one bit in table's header - now it involves RI and other heavy DBC artilery, so if you destroy and recreate an index, it'll mess up the dbc... unless you destroy the connection to the dbc first, recreate the index, restore the connection. There are some other tricks involved, but it's still doable.

>Also, do you know of any setting which would simply remove the reference from the table without generating the error?

In this excerpt from my old indexing routine, cDbfName and cCdxName are the full paths to the filenames. The 100 byte which was written into the 29th byte was the codepage marker for codepage 852; you may want to leave that byte alone.

m.xx=fopen(cDbfName,12)
if m.xx>0
	=fseek(m.xx,28)
	fwrite(m.xx,chr(0)+chr(100))
	fclose(m.xx)
	erase (cCdxName)
endif