Save changes to disk during idle time

[QuinTech]

It appears that "idle time" may not mean what we think it does.

Using FMP6 on my local Windows XP PC, set to save changes to disk during idle time, I observed data loss under conditions which FileMaker claims should not cause data loss.

With a file open, I ran through several trials of

1. entering data,

2. performing some action, and

3. killing the file through task manager.

I found that when step 2 was one of the following actions, my data was saved:

• Switching layouts
  
• Defining fields

However, the following actions in step 2 resulted in data loss (the data I entered was not there when I re-opened after crashing)

• Pausing for up to 60 seconds before crashing
  
• Opening another FileMaker file
  
• Tabbing to another field
  
• Clicking to another field
  
• Exiting record (by clicking out of the field)
  
• Switching records
  
• Entering layout mode
  
• Entering layout mode and returning to browse mode

But FMP's website says:

What does "during idle time" mean to FileMaker Pro? At minimum, FileMaker Pro will save every 5 seconds. There are specific actions which will also force a save. Among these actions are: switching records, switching layouts, defining fields, switching modes, and closing or quitting.

Anyone with more knowledge than I care to comment on this apparent contradiction? Am I doing my trial wrong, or is FileMaker's claim incorrect? And if their claim is incorrect, are there any strategies for preventing data loss due to a crash besides backing up frequently or hosting files with FMS?

Jerry

[gdurniak]

Yikes! This does not sound good

The knowledge base does say "FileMaker Pro automatically saves your files during idle time unless you change the settings in Preferences. Saving during idle time means that FileMaker Pro will try to save anytime nothing else is occurring (i.e., running a script or entering data) but never more than every 5 seconds."

It would be interesting to try your test on the other operating systems, OS 9, OS X, and Windows 2000

There are SO many questions like this. I have already asked FileMaker to add a Developer's Conference session called "How FileMaker (Really) Works"

[Vaughan]

Try the test again, this time issuing the Flush Cache script step before killing the FMP application.

What happens?

Also when switching between layout and btowse modes, make a change to the layout (add an object then delete it) and see if that causes FMP to save to disk.

I could imagine the FM developers minimising data traffic by only saving to disk if a change has been made.

[QuinTech]

Gregory said:

It would be interesting to try your test on the other operating systems, OS 9, OS X, and Windows 2000.

I'll give it a whirl on Windows 2K, but I expect behavior to be the same (although, if you read further, you'll see what my expectations are worth). I'm not even gonna bother with Win98.

I'll try it on OSX, but I don't know how to crash files on a Mac in the way I would use Windows Task Manager to crash files. Can anyone explain that to me? Vaughan?

Vaughan said:

Try the test again, this time issuing the Flush Cache script step before killing the FMP application.

Here's a shocker: The data was not saved. I felt sure that running such a script was just going to confirm what I already knew, and that flushing the cache was the same thing as saving data from the paging file to the appropriate section of the hard disk. (Does anyone know if FM even uses the paging file? I would guess it does, but then, this program does a lot of things I wouldn't expect.)

To reiterate: I had a blank field. I entered data into that field, ran a script with one step (Flush Cache to Disk), killed the file in task manager, re-opened, and the data I had entered was not there.

Also when switching between layout and btowse modes, make a change to the layout (add an object then delete it) and see if that causes FMP to save to disk.

This does cause FM to save to disk. I entered data, went to layout mode, copied the one field on the existing layout (by doing a Ctrl-drag), went back to browse mode, crashed, then re-opened. Interestingly, while the added data was there, the copied field was not. So some data loss occurred, but only the last change made (the addition of the layout object).

If I do the same thing, but fail to re-enter browse mode before crashing, data is not saved.

If I do the same thing, but, instead of copying a field, I add a graphic object (in this case, a line), the data entered is not saved, even when I go back to browse mode before crashing.

I could imagine the FM developers minimising data traffic by only saving to disk if a change has been made.

Just to be clear: In every case I've described, a change has been made to data in a particular field.

[QuinTech]

Here's a question: Should I expect recovering the file to change the result? In several cases where I've seen data loss, I've had to recover the file before I could even view it. I suppose this might have an impact.

I will do some of my "failure" trials again, trying to avoid file recovery, to see if the results change. I may be able to avoid the recovery because I've noticed that it's typically only after the file has crashed several times that recovery becomes necessary.

[gdurniak]

Yes, you must consider the possibility that crashing the file has caused damage / corruption

As a minimum, the test should start with a "clean" copy each time

Also, keep in mind that you are testing FileMaker "off label". FileMaker makes it very clear that all bets are off, if FileMaker crashes. Still, it's not to much to ask that data, supposedly written to disk, would survive

[QuinTech]

No kidding! I wonder what, exactly, they think "Flush Cache to Disk" is supposed to mean?

Sign me up as the second attendee for the new DevCon session!

Will post more results, taking file recovery out of the equation, later.

[QuinTech]

Tried again, this time making sure I never recovered a file. These actions resulted in data being saved:

• Opening another FileMaker file
  
• Defining fields and returning to browse mode
  
• Clicking out of the field, then running a script that flushes cache to disk
  

These actions resulted in data loss:

• Switching layouts
  
• Pausing for up to 60 seconds
  
• Defining fields and failing to return to browse mode (crashing with field definitions open)
  
• Tabbing to another field
  
• Clicking to another field
  
• Exiting record (by clicking out of the field)
  
• Creating a record (neither the edited data nor the newly-created record were saved)
  
• Switching records
  
• Entering layout mode
  
• Entering layout mode and adding an object
  
• Entering layout mode and adding a field
  
• Entering layout mode and returning to browse mode
  
• Entering layout mode, adding an object, and returning to browse mode
  
• Entering layout mode, adding a field, and returning to browse mode
  
• Running a script that flushes cache to disk
  
• Tabbing out of the field, then running a script that flushes cache to disk
  
• Clicking to another field, then running a script that flushes cache to disk
  
• Switching to another, already-open, FileMaker file
  

Notice that, in my first round of trials, switching layouts caused data to be saved, but in the second round, it did not. ("Opening another FileMaker file" moved from the loss list to the save list, but this is because of my error -- in the first trial, I was switching to an already-open file, not opening a new one -- so I would expect the second trial to be closer to real-world conditions.) I am fairly certain I held everything else constant, at least, those things that were under my control; so it appears that there are things not observable by me that have an impact on the reliability of the data. Which makes data loss, to some degree, practically random, unless someone can determine what the unobserved factors are.

I could test thousands of other scenarios, but, well, that's really not my job.

What's more, in at least one instance, crashing the file gave me, upon the next opening, the dreaded "access privileges" corruption problem. I was testing on a file with 2 text fields, no options, two simple layouts, no scripts, no value lists. So even a seemingly innocuous crash (which, 99 times out of 100, causes recoverable corruption if any at all) may render a file useless.

All of which means that I am now more unsure about when, how, and why FM saves data than I was when I began this process.

[gdurniak]

you say "So even a seemingly innocuous crash ... may render a file useless"

yes, and many developers don't know this. More importantly, a file does not even need to crash to become corrupted.

you may have already seen my post on corruption here: http://masdevelopment.com:3455/1/57?view=print

I believe if you tried your tests with FM7, it's "survival" rate might be worse than FM6

[QuinTech]

WORSE than FM6? Oh, dear.

I've read your document. It's enlightening and discouraging. (BTW, I notice you don't have a link for the FMP Consistency Check, Article 103745, in your Additional Notes section. If you google filemaker "Article 103745" and use their cached version, you can see that article. Or use this link.)

[Lynn Johnson]

I can confirm that at least one of your fail to save test conditions also fails on the Mac OS X in FM 7. Switching layouts followed by a Force Quit does not save the last data entered.

On Mac OS X Force Quit can be found in the Apple Menu or by pressing Command+Option+Escape.

Lynn

[QuinTech]

Thanks for the confirmation, Lynn. This is discouraging.

More fuel to the fire: The client who inspired me to start this avenue of inquiry lost two hours' worth of entered data because FM crashed before the "cache" could be "flushed" to "disk". (I'm using quotes because those three words apparently have non-standard meanings in this context.) I remoted into his computer and inspected everything that could be inspected, and the data is not there, it is just gone. That's TWO HOURS of data that Filemaker did not save!

Oh, boy.

[Lee Smith]

Hi Jerry,

You are sure that it crashed, and not that the users were entering data in Find Mode? It wouldn't be the first time.

Just a thought.

Lee

[QuinTech]

Hi, Lee, and thanks for the suggestion. I am sure that it crashed; the user even reported the error messages that appeared ("This file is damaged"/"Filemaker cannot read the disk" [bTW, I am certain the hard disk is not the problem]).

Second question, was he in Find mode? This had occurred to me previously, because he had mentioned that if he enters ten records and closes the program, the recurring crash he's been suffering from does not recur. Knowing that FM will warn you when you've done ten find requests in a row, I wondered if this was coincidence or something more.

I am now convinced it is coincidence, because

(1) We use SecureFM to make many commands inaccessible in the traditional ways. The View menu is typically not accessible in our program, nor can the dongle at the bottom left be changed from Browse to Find (what is the name of that thing, anyhow?), and Ctrl-F is a dead key.

(2) On the off chance that the user did somehow get into Find mode, virtually every action in the program is scripted, and most scripts contain steps accessible only in Browse mode. Thus, had he been in Find mode, he would almost certainly have been taken back to Browse mode in a short time.

(3) If he enters ten records and exits, the data is saved, which suggests to me that Find mode does not occur to him as an option and is not entered automatically.

(4) I am occasionally able to reproduce his error on my own machine, and I am sure I am not in Find mode.

I can't rule out Find mode with complete certitude, but I think the above points make it certain enough that I have to consider other problems.

J

[gdurniak]

Amazing that Google still has cached copies of old FileMaker TechInfo Articles. I added a link for the Consistency Check. Thanks!

Also, whenever there is "missing data", make sure there are no duplicate copies of files on the server, OR on any local hard drives.

Edited July 19, 2005 by Guest

[QuinTech]

And thanks for your article, I find it quite valuable.

make sure there are no duplicate copies of files on the server, OR on any local hard drives

Confirmed. This was the first thing I checked. There are no other files available to him.

[xochi]

Somewhat related -- I was doing some record creation speed tests with FM 7 Server on tables with calculated fields, and I discovered that the "flush when idle" setting gave markedly worse performance than setting a long flush time (such as 30 minutes). It seemed as if "idle" was deemed to be in the middle of a tight loop, which is pretty much the opposite of my idea of what "idle" is.

Moral of the story -- a long, fixed cache flush time may give better performance than "idle" in some cases.