>Fabio, yes I remeber now, I have read a longtime ago something about that.
>>Gojko, now remember this issue ( a bug ). I post it some months ago.
>>The first time, besides producing the error, VFP removes the definition of the cdx,
>>in this way the second time cannot verify him the error.
>
>In fact, missed CDX I can check like any other file with FILE().

Uses FILE() for this task is a error on a multithread OS.
Example: you check FILE(cdx), and a ns after another thread delete it!

> I did that and if that is right I return file back from EXE with STRTOFILE ( FILETOSTR(...),...).(I include previously in projet copy of CDXs). It seems it works ( idea is not mine, read somewhere somebody did something like that ... ).

It seems good but it is wrong.
He thinks about two consumers that the same thing contemporarily does,
one of the two an error finds again him in the procedure of recovery of the cdx,
and a good program never has to produce errors during an attempt of solution of another error.

>Now, for errors like 114, corrupted CDX, how can I
>recognize them in advance and do the same but with esacping messages Cancel - Ignore, which
>confuses users ? ( I am considering to purchase SDT , but not at his moment ).
>Many thanks, Gojko

The VFP message error

114 Index does not match the table. Delete the index file and re-create the index.


it furnishes the answer to you:
1. delete the cdx file
But now you are in the same situation of the preceding case,
and then the solution it is immediate.

Then you reverse the logic and the solution, it comes natural
- before try to open the table
- if an error happen solve it
but you remembers,
the creation of the cdx (or with a command or with a copy)
you must have done only when you have succeeded in having
the exclusive access to the table.