how can i really mess up a file?

[stefangs]

hope this is the right section...

i'm trying to walk customers through recovering files. i've given them basically the info that's stated in the developer edition's handbook. one guy wrote to me recently saying that it worked ok, but the messages he saw were quite different from what said they would be. apparently there was a question along the lines of ' the data is not synchronized, do you want to synchronize the data?' or something. i wanted to try this and did all kinds of stuipd things to bust a file like force quitting in layout mode and stuff, but the file always comes back up after the normal consistency check. so here's my rather unusual request - how to ruin a file so i can practice recovering and gather some practical data on the procedure.

[Anatoli]

Maybe changing something in head section with hex editor?

[jeffer]

First...when a filemaker database crashes...don't use it anymore!

Data can get corrupted and you end up with a "broken" database!

If you want a file to be really broken...unplug your harddisk while working with it! No garanties givven! (its your computer...watch it)

jeff

[stefangs]

hmmm... for now i'd be happy with a broken FM file. i'll leave discussing broken hardware up to the folks in other forums ;-)

[DykstrL]

Most of the time when a file gets corrupt is when something is interrupted during a disk write where FileMaker is flushing the cache to update the file or writing data to the file.

If a lot of records or data have been deleted from a file - when the file is closed, FileMaker scans and removes (packs) extra file space reserved for the file. If something happens at this stage, it almost surely guarantees a corrupted file that will not be recoverable.

If your users are having crashes that are corrupting filemaker files, I would first want to find out why those crashes are occurring and try to make your solution files more bullet-proof: Are they trying to do something that is not designed for in the solution? Are they trying to stop some action or script that is running? Have you given the users easy ways to get out, stop scripts, or even exit the application? Is your solution cross-platform and if so, has it been thoroughly tested on all platforms ( I now consider OSX to be a separate platform from the other Mac OS's)?

I am responsible for a runtime solution package of electronic forms that is distributed via CD and the web that currently contains over 300 FileMaker files. We have been doing this for over 6 years now. In all this time we have only had calls for 2 corrupt files - and the last one was over 4 years ago.

[Anatoli]

Excellent points.

RE: I now consider OSX to be a separate platform from the other Mac OS's

Absolutely. After easy Mac OS and Windows I don't want to start with Unix.

I had enough command line interface from DOS.

[stefangs]

in the case where this corruption happened (actually the first one that i've heard of), i'm pretty sure it wasn't as a result of the solution code, but because the customer's computer crashed. my solution is of the type that typically sits open in the background all day while you work with other applications in the foreground, and switch back every once in a while.

possibly the user has made some entries that hadn't been flushed to disk, then switched to some other app which then crashed. for now, i have opted to put 'flush cache' commands on all buttons which contain a navigation to another file. that's a lot of flushing, but i don't think there's any harm in that and i *assume* that it would increase file protection a lot.