>>It depends on the nature of the index corruption / error. I've observed some odd errors that can only be corrected by physically deleting the CDX and recreating it. In other cases, completely dropping the TAG and re-creating it.
>>
>>In general, REINDEX will always work properly, but if the index is corrupted it won't always correct it.
>>
>>It's better to use ATAGINFO() and construct the INDEX ON commands, then DROP TAG ALL, delete the CDX, and then rebuild each tag from scratch.
>
>We do that or something similar, the only issue that you need to be careful with is if you have file rights, we have some files where we granted rights to individual files (not to folders as we did not want them to access all the files on the folder) to some users, the problem is that when you recreate the indexes, the CDX file is new, and then it loses all the rights, it only inherits the ones for the folder.

Put all of your data files in a data\ folder, and give those permissions only on that folder. You can run a background process to report any unexpected files that appear there, or simply auto-delete them.

>Then things quickly escalates to a disaster, as the user still has access to the DBF and when it tries to use it, FoxPro sees in the header of the DBF that there should be a CDX but it cannot open it, so... it REMOVES THE FLAG OF THE HEADER OF THE DBF before it opens the table. Now this user, and every other user gets errors for there are no more indexes.

Undesirable. :-)

>We have an utility that recreates the indexes of all files, which we run regularly (every month) to avoid overgrowing cdx or memo files and to keep them in "better" shape, but we first backup the user rights of this CDXs and restore the rights after the reindex finishes, we learnt the hard way :)

Do you have a utility that can rebuild the .CDX files while they are in use? We could use one of those in one of our projects.