Corrupted file or object - How does it happen ?

[Ugo DI LUCA]

I already dealt twice with a file or object corruption problem, without knowing that this was the case (FM quits, Relationships broken or field defs changing... )

Can someone point out the process of corrupted file. How and why does this happen ? How to prevent it ? Is it possible to have a "diagnosis" ?

[cmartin]

For an example of a field definition changing, please see:

http://www.fmforums.com/threads/showflat.php?Cat=&Board=UBB16&Number=60209&Main=60104#Post60209

Once corruption is identifed, can someone also please address the best way to fix.

Thanks-

Courtney

[Lee Smith]

What are you two doing? Hiding?

This should be an interesting thread. AFAIK, it's a black fuzzy area.

Lee

[Chuck]

Corruption is difficult to fix. The best remedy to avoidance.

You can't guarantee that you avoid corruption, but there's a bit you can do to reduce the likelihood. Corruption usually happens when FileMaker quits without properly closing the files. FileMaker doesn't have a save function, remember, so changes to the database file are written to during idle times, when the user or server isn't doing anything else. When a database is closed properly, all unsaved changes are written to the disk, but if the program or computer crashes, then those change haven't been written. If the program was in the middle of an operation with a script or user command, that operation could have left the database in a corrupted state.

You'll see the results of this when you open the files again and FileMaker brings up a message saying that the files weren't closed properly and it's doing a consistency check.

The way to decrease the likelihood of corruption is to not use database files that have not been closed properly. Use a backup of them instead. I pretty much back up my database files about every hour or so. If for some reason the program or computer crashes (I can't remember the last time this happened now that I'm using Mac OS X), I go back to the last backup of the files rather than use a possibly corrupted version. Yes, this means I have to do some of my work again, but I would rather do that than find out later that the files were corrupted and couldn't be fixed with the consistency check.

Another thing you can do is to include the Flush Cashe to Disk script step in a script that is run often. For instance, all of my scripts start with a call to another script called Script Start, which checks for which mode the system is in (user or developer) and sets up the status bar as appropriate. I could place a Flush Cashe to Disk script step here, and every time a script runs the chages to that point would be saved to disk. This will happen even if the system has been very busy and hasn't had the idle time necessary for writing to disk.

If you come across a corrupted file and either don't have a backup or don't want to redo all of your work, perform a Recover on the file (under the File menu). This command can fix many problems that the built-in consistency check cannot.

Once you've opened a file that wasn't closed properly or performed a recover on the file, check the names of objects (fields, layouts, scripts, etc.) to see if any of them now are called "Recovered". These were so damaged that the Recover command couldn't do anything else. Check your calcs and scripts and layouts to see if you can find out what the original name and purpose of the field was. Analyzer from Waves in Motion is a good tool to help you find these references. Then delete the field and recreate it.

If you find that one field or layout or other object is causing problems, recreate it.

Avoid crashes of the system as you can. I can make better recommendations for how to do this on the Mac, but I'm sure others here can help with Windows. On Macs, especially Mac OS Classic, pare down your extensions and control panels. Get plenty of RAM and give FileMaker about 40MB of it. If you find that you're having lots of system crashes, do some troubleshooting to find out which extension or control panel might be causing it and remove it or, in case it's corrupted, replace it with a fresh copy. Make sure you have the latest update of FileMaker for the version you're running.

But like I said, the best remedy is avoiding it, and the only way to avoid it is to not use files that could have been corrupted, so back up your data. Make it easy on yourself. I wrote an AppleScript that will backup the currently open FileMaker files, giving a date and time stamp to the name of the archive (created with StuffIt Deluxe). On OS X, I use DragThing to tie this AppleScript to a keyboard combination. I hit that combination and the script closes my files, creates a date/time stamped archive and opens them back up for me. The process takes about 30 seconds, time enough for me to refill my coffee.

When your databases are actually being used, again, regular backups are the protection. You can set FileMaker Server to backup quite often, but corruption may not be found for some time, so your backups may be corrupted too. Keep daily backups for a week, weekly backups for a month and monthly backups indefinately. When there's a problem found, find the last good backup, which may take some time, and use it as your working copy. Perform a recover on the corrupted files and import the data from them into the working copy. Continuing to work with corrupted files is just an invitation to later headache.

Chuck

[Ugo DI LUCA]

Thank you for the clear answer Chuck. I wasn't aware of all these tips even if I've programmed a 1 hour backup...

but corruption may not be found for some time, so your backups may be corrupted too.

Right....I already came accross that situation.

Lee,

I was accidentaly still logged in, just working on my files Not hiding at all.

[cmartin]

Chuck-

Most appreciative of your thoughtful and detailed response. FM had shutdown improperly quite recently for me and I buy that this could be the cause of my corruption.

Thanks!

Courtney