Power Loss & Trashed Designs

[LaRetta]

I have a very very bad habit. I put my head down and tear into my work (at home). When I look up, sometimes days have gone by. And I don't remember anything except what I've been working on.

When I'm *present*, I back up every hour minimum. Why am I telling you this? Because I just had a power failure on my home stand-alone system - in my design that is used every day. And I've done major changes to it (like always). And I realize (looking at the clock) that the last time I backed up was 12 hours ago.

I have asked this before on power loss of hosted file. I know I need to trash the design if it happens - the risk of corruption is too great. But I don't want to lose a full day's work. Consistency check ran and said it is fine. I was in my LineItems 500,000 records. When it crashes while hosted, it is LineItems that always takes a nose dive (by mis-counting/displaying number of records, or some records perm locking with 'no access'). I have looped through my LineItems with Set Field[ ] and it worked fine - all records set properly; all records accounted for.

I will not risk our design, no matter how badly I want to save my work. But, is it safer to crash stand alone than hosted? I guess that's like asking if it's safer to get hit by an 18-wheeler than a bulldozer. But I need to ask.

Do ya'all ever risk it or do you always trash a design if it crashes? PERIOD. I do not trust Recover (and rightfully so). It has told me a file was fine when it was junked. I don't know if I'm being paranoid (for not risking it) or extremely foolish (to even consider keeping it).

I'm sitting here a bit numb. Input (one way or the other) would be MOST appreciated.

LaRetta

[Fenton]

An analogy. A strange spot has appeared on my skin. There is less than a 1% chance that it will lead to terminal cancer. Should I remove it, or just hope for the best?

The problem is that there is no way to know if there is any corruption. It would probably be OK if there was no alternative. But, for better or worse, there is. Which is to go back to a good copy and try and recreate what you'd done. On the plus side, it will take far less time the 2nd time. On the minus side, you might forget a tweak or two. But you'll probably remember someday. Think of it as penance, like writing, "I will backup my work" a thousand times. Or, for the optimist, "It was so much fun, I'm going to do it again" :-]

Yes, I know, not very funny. I've paid that dues, however, more than once, more than twice actually. It's the hidden price of being a developer. But I'm sorry it's happened. And to all you developers who've never faced this problem because you're just perfect; we hate you :-|

It's a good time to pull out the paper (or word processor) and outline what you did. Get the overview first, then fill in the gaps. With the crashed files still in pretty good shape, for reference, you shouldn't have too much trouble getting most of it back in a fairly short time. If time is pressing and the files must go back into production, let them. Then import later into the repaired clean copy; 500,000, yikes.

[LaRetta]

Oh Fenton, thank you and I needed the laugh!

I'm hoping for a mass of responses from Developers whose combined (several hundred) years' experience, having had a total of 500-1,000 such crashes can help me predict the damage odds and then identify the break point. In fact, if everyone on Forums responded, I'd have pretty solid stats. Are my attempts to bargain with the price too terribly obvious?

... to all you developers who've never faced this problem...

It's fact that I will never fall off a horse I don't ride. It's just that my butt gets so darned sore from hitting the dirt so often. This issue isn't discussed on any forums and if something isn't talked about it will keep happening to others (being tempted to use a trashed file and not remembering to back up often enough). I guess it's a Developer closet-issue like admitting you've had unsafe sex (everyone has done it but nobody wants to admit it).

Hmmm ... the odds and consequences are similar also.

I just set up an alarm clock next to my ear which will blast me every single hour. That should get my attention even if I'm in the middle of a juicy calculation! Friday night I had outlined my weekend work on my whiteboard so no prob there. So I guess I'll slink off and pay my price ... that is ... unless I get a high (very high) statistical response (from thousands of people) saying it'll be fine (for absolute sure).

My dog assures me it'll be fine.

LaRetta

[gdurniak]

LaRetta,

I have compiled everything I know about file corruption here:

http://masdevelopment.com:3455/1/57?view=print

To answer your questions:

1. yes, I have risked using a crashed file, when time did not allow

2. hosted files are better, if the client crashes. But, if the host crashes, you may still be screwed

3. from anecdotal evidence, posted here, it appears that the consistency check and recover command do not work as well in FM7. For the first time, many developers are surprised to find that recover often can not open damaged FM7 files

4. if you develop using FM server, as many developers do, you can schedule a backup every hour

5. FileMaker had the nerve to market FM7 as "un-corruptible". Obviously, this is not true.

[Fenton]

Here is another definitive answer, from Jimmy Jones of FileMaker Inc.

Background:

I was the FMI technical support person responsible for getting corrupted files repaired back in the FMP 3/4/5 era. I have seen literally hundreds of files that were corrupted in more ways than I can count.

Please believe me when I say files do get corrupted and in ways unidentifiable by the user. (No surprise there because FMP doesn't have any tools to show corruption). The primary way a served file exhibits most forms of corruption is as an instability in serving the file. In other words the file unexpectedly closes. The second most common is the file won't stay open on a client's computer.

There are many forms of corruption. Some may sound like they shouldn't be a problem, for example a font reference to a non-existent font. But this belief is wrong. A bad reference to a font can cause a whole layout to become unusable because it closes the file whenever that layout is used. Text in a field that has a bad font reference can cause that record to become inaccessible because the file closes every time the data of that record is displayed.

Using a file that is improperly closed or that has been recovered is taking a chance with the customer's data. I cannot in good conscience use a file that could result in loss of data and possibly thousands of dollars in recovery costs, if it is even possible. Having had to do this with a corrupted file on a user's system I know it can cost that much in labor and lost productivity.

__________

Regards,

Jimmy Jones

FileMaker 7 Certified Developer

[Walter B]

Being a long time developer on a number of different applications and systems, spending a great deal of time attached to data centers, I have my have all my systems on a battery backup of some kind. You can get a reasonably priced UPS (under $200) that will at least give you time to do a graceful shutdown during a power outage. +/- $200 seem a small price to pay to me.

[kiwiora]

I had a database crash, which to this day FM Techs cannot fathom. Create a table, fields and records, close the database the table would disappear. Re-create the table and the fields named exactly the same and the data would re-appear ... closing down again would naturally make the table disappear again.... what the.

I, like Jimmy Jones, will not risk a "might" because "might" is too big a word in my book using the recovery tool. I recreated my entire database from scratch. Using printouts from the recovered database makes it so much easier (all the blood sweet and toil creating those calculations/scripts is done, all you need to is copy-type essentially).

[flapjacks]

This is exactly why I drink heavily when I write.

John

[kiwiora]

I swear even though I was completely sober, if i didn't have another FM Developer sitting next to me witnessing it all I would have thought I was completely delusional.