question

A fairly large table had an error and required executing repairs until REPAIR_ALLOW_DATA_LOSS was the only thing that fixed it (restore from backup would be the best solution.). Of course, there was lost data. I was able to compare a couple indexed fields to a backup copy of this table and identify which records were lost (15 lost out of +980K). **Table Usage:** Load production data every month (a date column to indicate month end). Users go through an approval process for the current period under review and can update or reload batches to replace existing records. Once approved (around 15th of the month), the are locked out of the data. I'm discovering the previous backups have the same error. I don't know what caused it or when. I'm approaching the point where the most recent "good" backup is going to be before the last update to the table (Still restoring), so I won't be able to compare all data (rows & columns) to see what is missing. I only know the PK which is probably due to only needing the index to query/compare. Is it possible that a part/column(s) of a particular row may be missing data or does this pretty much wipe out the entire row? I may not have the luxury of a good backup to compare or reload all the data. Based on the repair messages, I think it is the entire row. ERROR: CHECKTABLE found 0 allocation errors and 1 consistency errors not associated with any single object. * indicated all indexes were repaired * the itemized errors indicated: (type In-row data)