Comments on: Dealing with Damaged FileMaker Files

By: Geoff Coffey

Geoff Coffey — Tue, 12 Jan 2010 16:57:48 +0000

Michael:

I agree. Any takers?

Some day we’ll get back to writing. I miss it.

Geoff

By: Michael Kupietz

Michael Kupietz — Sat, 09 Jan 2010 01:35:37 +0000

This could really use an update for FM v10.

By: Lars D

Lars D — Wed, 23 Sep 2009 13:55:19 +0000

Idle “anything” server:

When a disk becomes unpowered, it has a tendency to just drop what ever it had in the buffer/cache, to disk. It will drop it anywhere on the disk.

To counter this, you should have hardware configure properly. Essentially file system corruption.

By: PaulB

PaulB — Fri, 13 Mar 2009 19:56:44 +0000

I wonder why losing power to an idle FMP Server would cause corruption? I’m new to FMP, coming from 4th Dimension, and I never had file corruption problems in 4D in 15 years with apps running on 4D Server the entire time. 4D Server flushes data to disk on a regular basis, so unless the server is writing at the moment of failure, the files are always in good shape. FileMaker should adopt this strategy so that your files are only vulnerable during the moments when they are being written to.

By: Geoff Coffey

Geoff Coffey — Wed, 17 Oct 2007 20:57:48 +0000

@bryan: The most likely explanation is that you do have some under-the-hood corruption that just has no visible impact. FileMaker 9 does something called a consistency check on the file when it is opened to look for corruption. It does this to help detect problems early before they’re likely to lead to major problems.

In your case, the consistency check is failing so 9 is complaining that the file is damaged, even though in 8, where no check is done, it runs “fine.”

In most cases, simply saving as a compacted version in 8 or 8.5, then re-opening in 9 will fix this problem. It sounds like that isn’t working in your case. You may need to try a more aggressive approach. Have you tried recovery (I know…bad word…try it anyway, at least to see if it gets the file open-able in 9). Also, sometimes it works to clone the file, then save the clone as a compacted copy, then re-import the data form the original. Do this all in 8 or 8.5, then try opening in 9.

Let us know what happens using the Contact Us button above.

By: Bryan

Bryan — Wed, 17 Oct 2007 20:29:07 +0000

Good dialogue here… in our case we did not see any errors or corruption until updating from 8.5 to 9.0. Does this imply an error that was lurking but not seen (likely from a previous Server crash), or does this imply some issue with FMP 9?

We haven’t had any luck with compacting or recovering… the database is functioning as best we can tell on 8.5.

Since this same behavior (only indicating corruption when opening in 9.0) on several files, makes me wonder.

By: Importing Records to a Backup - Brute Force at Six Fried Rice

Importing Records to a Backup - Brute Force at Six Fried Rice — Thu, 13 Sep 2007 19:19:52 +0000

[...] Dealing with Damaged FileMaker Files [...]

By: mr_vodka

mr_vodka — Fri, 07 Sep 2007 19:56:23 +0000

Hey Geoff and Jesse,

Just as a FYI, Thatcher’s presentation is available for download on the DevCon update site now. The link is in the DevCon binder and is under “Conference Information” of the General Information tab just in case you werent aware.

By: Tom Gelin

Tom Gelin — Mon, 27 Aug 2007 20:53:39 +0000

I spent the better part of a week recovering a database with 2 million records. I didn’t compact or recover the original file. What I did was export 60,000 records at a time to an Xcel file. Then imported them into alphabetical FMP9 files. In the process I had numerous crashes but by importing the files alphabetically I only had to start over for the particular character. After I had all of the A-Z files I then imported them one at a time into a master file. Not a very pleasant experience, but it worked.

By: Beatrice Beaubien

Beatrice Beaubien — Mon, 27 Aug 2007 04:30:10 +0000

In his session, Jon Thatcher solicited our ideas about how the report after recovery could be improved. I’d take this offer seriously. For example, we could request a result that went into detail into what didn’t have to be changed. “This file did not appear to need recovery.” That would at least tell us nothing was changed. Or a verbose description as to what was actually changed. Or even a take on whether the data resulting was worth recovering, how many blobs were lost and how many were rescued, etc. The engineers get a fair amount of info back from the recovery process and (apparently) we can request that it be put into a report, like the Import or Conversion Report.

Your constructive ideas to the engineers can go into the Help -> Send us your feedback selection in FMPA9.