Corrupted files (WAS Recovering Deleted Records)

[T-Square]

This still appears to be the best place to follow up on my earlier post regarding recovering "deleted" records.

I had been trying to recover records that a client had deleted, but the circumstances were stranger: the records were deleted in the source data file, but still visible through a portal in another file. Although I cannot for the life of me see how I could view records from one vantage that were not visible from another, I can say it has something to do with the fact that my client somehow inserted records into the table in question without a required key field, and this somehow corrupted the data table.

Now, for anyone who might encounter such a strange circumstance, I will tell you that you CAN export data that isn't "there" in one table, but visible in another layout. All you have to do is use the layout where the records are visible to perform the export. Export the fields from the portal into a new FM file. Then, because the data is corrupt in the data file, you have to save a clone of the current data file and import your records (minus the erroneous records) into the clone.

I admit I felt pretty much like a guitar god at the moment when all the records were back in my client's file.

[Vaughan]

"Then, because the data is corrupt in the data file, you have to save a clone of the current data file and import your records"

I'd recommend importing into a *known-good backup* of the data file. If none exist then re-build it from scratch.

Re-using a clone or recovered file is not really an option, it's history repeating itself.

[T-Square]

Vaughan--

You say I should use a "known-good backup". Is there some way of knowing what is a known-good backup?

I work on a development copy of my software, and then (for this customer) import their data into a clone of the development copy. But I have no way of knowing whether my devel copy is clean. It works. But you caution me that even though it's working, I might still have corruption somewhere in the file.

I don't see how I can ever be sure a file is clean; I also do not know how I would clean a copy that was found to be corrupt, if recovering, cloning, and compacting don't do it.

You say "rebuild from scratch". In a complex application, you're talking about many tables with many potentially complex field definitions and many relationships among them. Doing that by hand would take hours, and probably days. Perhaps you know of a way to use the Database Design Report to do this programmatically?

If you could clear some of this up for me, I'd really appreciate it!

Cheers,

David

[T-Square]

Further reading out there (see e.g., the New York Filemaker Developer's Group at http://masdevelopment.com:3455/1/57) underscores that this is a big black hole. There does not seem to be any way to be sure that your FM files are not corrupt, and there do not seem to be any tools that will assure a developer that their files are not corrupt.

So, essentially there is no way to use a "known-good backup", as there is no way to be certain that ANY Filemaker file is clean. One can be somewhat sure or even pretty sure, but there is no foolproof guarantee that the file you are using as your known-good backup isn't harboring some hidden corruption that will some day reach out and bite you.

Yikes.