1) What is your INDEX ON command to create the last key? Maybe you are confusing the data engine, for example by using a keyword as a variable name. This would cause the incomplete DISPLAY STATUS, and also the error message when VFP tries to update the incomprehensible TAG. It appears you have a field called "Record". Maybe Fox can handle it (or maybe not), but in any case I would strongly recommend that you change the name to something else that is NOT meaningful to Fox. It will make you code more readable, and it will avoid the potential for problems. Anything that turns blue in the code editor should NOT be used to name a field, table, tag, variable, etc.

2) I would recommend not using the FOR clause at all in your INDEX ON command.

***
Here is a section from VFP 7 Help, under "Rushmore technology":

Indexing Effectively for Rushmore
Rushmore cannot take advantage of all indexes. If you use a FOR clause in the INDEX command, Rushmore cannot use the index for optimization. For example, because it contains a FOR clause, the following statement cannot be optimized:

INDEX ON ORDNUM FOR DISCOUNT > 10 TAG ORDDISC
Similarly, Rushmore cannot use an index created with a NOT condition. For example, the following expression can be optimized:

INDEX ON DELETED() TAG DEL
But this one cannot:

INDEX ON NOT DELETED() TAG NOTDEL
***

I would suggest this:

INDEX ON AC_NO2+DTOS(DOC_DATE) TAG T1

If you only have 31,931 records you hardly need any other optimization; if you have 319,311 records, it will help.

Perhaps INDEX ON DELETED() TAG T2, if you have many deleted records. If less than 10-15% are deleted, you don't need this.

The fewer tags you have, the less likely you will lose the synchronization between the table and the index. The good news about the error message, "Index does not match the table..." is that you haven't actually lost any data.

Also, Rushmore cannot optimize EMPTY(). To take advantage of the TAG T1 above, your FOR or SQL WHERE clause needs to look like this:

FOR AC_NO2+DTOS(DOC_DATE) <> SPACE(LEN(AC_NO2))
(or)
FOR AC_NO2+DTOS(DOC_DATE) <> ' '

(It is faster to use as many spaces as the width of field AC_NO2, but then if you change the field width you have code maintenance.)

You may or may not gain performance from these tags:

INDEX ON Post TAG Post
INDEX ON nRecord TAG xRecord && changed field name

If "Post can only be "Y" or "N", and you have roughly 50% "Y"'s and 50% "N"'s, the TAG won't help anything. If you only have 5% "Y"'s, definitely index it. Don't use the "==" operator - it isn't optimizable, and if your field length is only one character the "=" operator produces the same result.

I agree you should drop this table out of your DBC if you have one, while you are fixing it.