Bill Arnold wrote: > Mike, > > I think you have to consider that the implications of the corruption may > extend beyond the obvious. > > How about restoring a recent backup to "work table A", then repairing the > corrupted table into "work table B", and then comparing A and B to produce a > report of changes made to the data since the backup was taken. If all is > good, B replaces production table, otherwise you'll have to deal with > differences next, or go with the restored backup. > > Also consider using 'audit trails' for changes made to production tables, in > addition to regular backups. This gives you another resource to use in > database recovery.
It's not corruption. It's a bug in their software that is causing this. However, it's only on rare occasion...not every record in the table suffers from this. The fortunate thing is that they've killed that project, so their buggy software won't be polluting our waters any more like this. However, I still have the cleanup issue with which to deal. I'm fully for audit tables; however, these jokers didn't use that. (And I guess perhaps that's good, because they would have hosed that up too!) _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
