That was one of the first things I tried. You know that great inheritance thing? well, it thinks the indexing procedure is part of the error handler, so it won't touch it. *shrugs* I'm going to try out Larry's code, and see what it can do.

Thanks for your advice

>Don't try to fix the problem in your error procedure. Once you have the name of the table, pass that tyou your indexing proc. The indexing proc should be where you try to open the table exclusively. Then you get the Structural CDX not found error generated, which will call your error proc again.
>
>BTW, I would not call my error proc ERR. Make it something that is not the beginning of a VFP reserved word.
>
>>The title actually does make sense. I've got your standard
>>
>>ON ERROR DO ERR WITH ERROR(), MESSAGE(), LINENO(), PROGRAM(), MESSAGE(1), SYS(16)
>>
>>One of the errors that traps is number 114 (Index does not match the table. Delete the index file and re-create the index). When I trap that error, I parse the code to find the table in question. Then delete it's CDX, and then USE it (and then later I INDEX it). Well, on the USE I get "Structural CDX Not Found". Ok, fine, I expected this. So I have (in the same ERR.PRG), If ErrNum=1707, Retry.
>>
>>Well, I found out that when you are IN the error handler, there IS NO ERROR HANDLING. If an error occurs, you are screwed. The help file even states that you cannot nest an ON ERROR statement. This is really bad.
>>
>>Anyone else came upon this? Is there any way to make VFP do ON ERROR RESUME NEXT (excuse the VB code)? I want to just completely SKIP this error (it has to run that USE to get rid of the CDX reference in the DBF).
>>
>>TIA!