Build a crash protector please!

[Rickb]

I want to build a script on an opening file that detects if the main file has crashed (error 805) then opens the backup file.

Any ideas?

[IdealData]

I'm not sure you can do this.

If the file is damaged then you can't open the file so you can't run a script in the damaged file.

Errors only exist for the current file, so don't see how you can run script from "opener" to test for damage in "other" file.

Not all errors are trapable

[keshalyi]

I don't chance to know the exact error you're referring to, but one solution to this problem might be to build a global 'LastShutdownValid' field. Make a script to run on close, that sets this to yes. On open, make a script that will first check to see that this field equals yes. If it does not, it cna prompt that an error occured during the last shutdown, and let you restore from backup or whatnot. Then set the field to 'No' so that if it goes down before the close script, you have an indicator that something went wrong.

[LiveOak]

I think we are avoiding the real problem here. Well configured FM Server machines running correctly designed files DON'T CRASH. Rather than spending a lot of time trying to think up ultimately unsuccessful strategies for recovering from crashes, why not address the cause of the crashes and take corrective action?

-bd

[keshalyi]

Philosophically, I agree with the sentiment. Yes, a perfectly programmed system should never EVER crash, and sure, Filemaker Server is tres, tres stable. BUT. At least for me, I will admit that I have never ever programmed a perfectly programmed database. So, stuff happens. Yeah, sure, when it happens I evaluate, and fix it, and then it doesn't happen again (hopefully), but in the meantime, I feel more secure knowing that if something DOES happen, then at least it will only hurt my pride. Not my data. Or at least have a better chance of it. I have grown paranoid, and I like to assume that every single thing I program will break at some point, so why not catch it, and react?

[danjacoby]

Oak, I'm shocked!

Even well configured servers will occasionally crash. Hardware wears out, as moving parts wear down and even parts that don't "move" will expand and contract due to heat exchange. Additionally, although digitized files theoretically have no "generational loss" when copied, the fact is that mutations do occasionally occur.

The result is that crashes happen. They're unavoidable. The most we mortals can do is try to minimize the probability of crashes and have backups.

It's an imperfect world. Enjoy it.

[SteveB]

What about the single user solutions that don't involve servers. They crash and corrupt files as well. Dan hit the nail on the head - Backup, Backup, Backup (kinda like location, location, ...).

[LiveOak]

It comes down to picking the solution that fits the need. If you haven't already spent time trying to find out and correct what is causing the crashes, it is folly to be spending time of some fix that might not handle the problem anyway.

At one client facility we don't see one FM Server crash a year, and they have FIVE FM SERVERS that have been running for 3 years. There are cases where automatic recovery is needed. In the few cases where we have seen server crashes, the Kick-Off restart devices bring the machines back up, FM Server does a consistency check, and all is fine.

I will stand by my previous opinion, if your crashes are so frequent or severe that you must use an extrodinary automated means of dealing with them, you are doing something else wrong!!!

The only FM application I've ever heard of that had this level of a problem was CALTRANS (Calif. Dept. of Transportation). Their level of use was so severe that they fragmented disk drives to failure in two days and would wear out high quality SCSI drives in 2 months. Even they found an architecture that eliminated the problem.

-bd

[Rickb]

Oak..

We have developed a reporting program to run on teacher's laptops. Teachers do strange things... shutting down in strange ways, batteries going flat etc.

We have built in a backup on start, regular automatic backups during use and a backup on close. Users can backup to floppy, the hard drive or the network at any time.

In the event of a crash we want FM to locate the most recent backup file and open it without inexperienced users having to locate the backup files.

Can't FM detect a crash when it attempts to open a damaged file as a script step then, if the Status(ErrorMessage)=805 is true, opens the backup file automatically, re-naming the same as the original file.

[Rickb]

Sounds like a simple solution....thanks, we'll give it a go!