Crash Recovery

[fed]

I unfortunately had a problem just before closing a database file. I am not sure what happened, but I think it was a hard drive issue. now my database is corrupt. I used recovery and all seems fine. I am reading that I should now use a back up database and import the new data. I have 12 tables and this seems like a lot of work.

1) Is it still the case that the recovered file could have errors in layouts and/or scripts?

2) When I check for consistency of the crashed file, I get "23747 total blocks, 23747 processed blocks, 9 bad blocks." What does this mean?

Thank you again for any help that comes my way,

Fed

[Vaughan]

The recovery process recovers DATA at the expense of everything else. If FMP thinks it could get some data out if it deletes some layout or script, it will. Consequently the recovered file may have some bits of layout or script missing, and in a large complex solution these missing bits are very hard to find.

It may be, however, that nothing was deleted. But it's a risk.

Hence the recommendation to recover the data, then import this into a known-good backup of the file.

Regarding importing into 12 tables: write a script to automate the process.

[fed]

Thank you.

What about these blocks? Do 9 damaged blocks mean 9 fields within records?

[fed]

I tried to import today's data into a recent backup (I backup daily), but I ended up with duplicate records. I used 'import' from file, and used 'update matching records' with 'add remaining records as new'.

Is there another way to do it?

I suppose I could import all the recovered data, but then I am assuming that all the data was recovered correctly.

Any help would be great. This sounds like it could be a real mess.

[Vaughan]

Save a clone of the backup file, then import the records over. Update all the primary key serial numbers.