VFP will not allow any recursive error routines. If an error occurs within the Error routine/Error event or with either in the program stack, VFP reverts back to the standard error display.

While I don't have a workaround for some things, this one I do. You could fix this directly yourself, if you want. Try the following:

local lnfile
lnfile = fopen(MyDBFFile,12) && open file read/write unbuffered
if lnfile > 0 then
   =fseek(lnfile,28) && go to position 28
   luvar = fread(lnfile,1)
   =fwrite(lnfile,chr(bitxor(1,asc(luvar)))) && remove bit setting corresponding to file having a structural CDX
   =fclose(lnfile) && close the file
   use (MyDBFFile)
   * rebuild your indexes here
endif

HTH.

You can get information dealing with the structure of a DBF file from the VFP Programmer's Guide - Appendix.

Also, the VB ON ERROR RESUME NEXT can be accomplished by issuing a RETURN from the Error routine. The line following the one that triggered the error will execute. RETRY will attempt to execute the same line again.

>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!