And another check ... to avoid 7038 errors which is when you have an invalid index. typically after a server crash, the client restores all the dbf's but fails to clear the cdx's

The 5004 error does NOT tell you the name of the missing part of the table ... dbf, or cdx, or fpt.

Especially 7010 errors on memo files - a simple zero the pointer record would be fine

We can detect some problem but sometimes we can not fix it.
- a memo corrupt: we must export to a new table
- an invalid date: we must edit it
- an invalid value: we cannot restructure it if an invalid value found in two or more field. we must edit it one by one before restructure it Or we must use FoxPro to restructure it.

// detect table's problem
TRY
DROP TABLE #tmp;
CATCH ALL
END;

SELECT * INTO #tmp FROM any_table;

// detect field's problem
TRY
DROP TABLE #tmp;
CATCH ALL
END;

SELECT any_field INTO #tmp FROM any_table;

// detect record's problem for particular field
TRY
DROP TABLE #tmp;
CATCH ALL
END;

SELECT TOP x any_field INTO #tmp FROM any_table;

File repair is our number 1 time waster. All the comments below are exactly what dreams are made of.

If we could have some way to verify the content of the ADM files associated with tables. Our #1 problem over the last 5 years has been corrupted BLOB's and memo's. Our users extensively store text and pictures and getting ADM corruptions or the possibility of them keep me up at night.

andorauk's suggestion of a checksum would be excellent. If I could only identify a problem as soon as it happens we can restore from a nightly backup. Most of our major issues(my customers yelling at me) come from not knowing the data was corrupt for weeks or sometimes months after it happens and not having a way to fix it.

Having the DB server app checking for corruptions as it writes and reads from tables and then send a message(via email) to someone would be a great help.

Would it be possible to [optionally] generate a 'checksum/parity/ecc/crc' index on a table and have this provide error-checking or some [limited] data correction? A table-check could be run against the data and errors optionally dumped out to an error-table?

Include ADTFix (Advantage Database Table Repair Utility) inside ARC (Advantage Data Architect).

I would second what pboivin77 said. I have a table right now with 9 corrupt records and 10+ thousand good records. If I could just port out the good ones and drop out the bad ones it would make my file repair work infinitely easier.

A side note issue I see frequently is if you have the "autocreate" set to true some times if the network is flakey it will wipe out your table and recreate it because it doesn't think it exists. the newly created table isn't bound to my dictionary anymore either, which just makes it even more fun.

Another popular problem: a FPT file disappeared, which results in inability to open a DBF altogether...

It is very important that changing the language did not corrupt the data, may be display error or even prevent open the table, but corrupt data for changing the language is not acceptable

Validate the table header with the .ADD metadata if a database table.

We must be able to copy good data to a new table. Something like "SELECT * INTO NEWTABLE FROM BUGGYTABLE WITH ERROR INTO ERRTABLE". ErrTable would contains a list of recno and field name with invalid data (Record 12: Field: CustNote Error: 7019 Corrupt memo field). Invalid field in the new table can just be blank, zero or null depending on the field type.

I can only pass to you my experience:
1. The most possible problem is a corrupt table, where we get a file with different header and actual size. To resolve this i just change the filesize to be equal to the header suggested and is ok! Some automation here?
2. Another possibility, is to have new records with wrong values (e.g. filed with zeros). An arc option to open table without index?