Record Commits and Computer Sleeps

Does anyone know if FileMaker Pro automatically flushes its cache when a computer goes to sleep?

As far as I know the OS is covering this. Apparently sleep should be transparent for apps and even interrupt scripts should continue after wake up where left off but that’s just theory as we know from go and server reconnect attempts…. I bet this is changing on every rev of FM due to optimization and bug fixes. Hope someone knows more.

I don't see how the OS has anything to do here. This is an issue between a client and a server.

A client app can continue where it left off prior to sleep, however a server knows nothing of this. From the server's point of view, it likely lost connection to the client. If the lost connection lasts long enough, the server will kill the client session to, among things, release locked records.

A client may be unable to synchronize records with the server when the client computer wakes anew and the session was killed by the server. The server may refuse any record creation, modification or deletion. If record creation was aborted, this could result in records disappearing from the perspective of the creating user.

I am trying to figure out if FileMaker Pro always attempts to flush its cache when the OS signals the computer is about to enter sleep mode. The cache flush would then happen PRIOR to entering sleep mode, when the client-server session is still active. I am, unfortunately, ill equipped to test out this scenario.

1 Like

I haven't tried, but it may be possible to open the console and watch the system logs as you put your computer to sleep and wake it up again.

1 Like

'normally' the OS is the boss of anything running on your computer without it there is no client nor server ..

(maybe in the past this was different when transactional systems needed a compare and swap instruction on the processor and tried to evade the OS .. )

I haven’t seen this kind of issue. One thing I observed is that with versions before 19.3 (FMS and FMP), reconnection after client wake-up failed frequently.
What are the concerned versions of FMS and FMP in the case you describe?
One option that could solve it is setting the ‘flush cache’ in Preferences to a delay shorter than the delay for the computer entering sleep mode.
Is disconnecting clients after an idle period activated on server?

Hello @bdbd,
I've been reading your OT and posts on the vendor's website and assume that the flush-the-cash issue your are investigating may be somehow related to the disappearance of records in a particular table.
In addition, the issue is intermittent, no pattern detected behind.
I've been chasing an intermittent issue recently, where records where not created and users did not recognise the failure.
In order to see what's happening when it happens, I added a script call to the routine in question.
The called report script received information as parameters and wrote them in a report table.
This gave me a track of all critical user actions in the context of the issue.

In the case of disappearing records, a scheduled server routine, running every 30 min, could check the number of records in the concerned table and write it to the report table. At each run, it compares the number of records with the previous value. If at a run, the number of records is inferior to the count of the previous run, it could be assumed that a critical event just happened and the admin could receive a warning email, sent by the reporting script.
Within that limited timeframe of 30 min, server logs can be scrutinised for client disconnections and events involving the concerned table, and users will remember what they just did. This may help identifying a pattern.

Happy hunting!


I know this is not helpful BUT a DBMS task is to handle this for you. Data integrity work arounds like this are pretty scary ..

Not a single system is flawless (even those driving aircraft, spacecraft or nuclear power plants aren’t). Sometimes we need a hands-on approach, when the system itself can’t help. :neutral_face:


MTF (mean time to failure) is never infinite but some transactional systems highly redundant are very reliable by design …

1 Like

I know, I know. We have a system, there is an issue (at present, it is not even clear if it is a system issue) and we need to nail it.
What do you suggest in order to find out what happens?

1 Like

I hear you and I am just flabbergasted that some systems sold as DBMS require to work around like hell to ‘fix’ what the are supposed to serve for … // sorry for being not helpful here as stated before

Well, they only thing I can suggest is patience - I know it's not great help.

I remember when I was providing support for SAP BusinessOne. A client had an issue where data disappeared, I know that should never happen. It was a procedure where they would send a customer a prototype of a promotional item, the the customer would reply, etc. Somewhere along the process, a entry was lost. It took me 4 months, not full time, to find out how to trigger the issue. I was looking back at the case once in a while, and suddenly I found the exact sequence to trigger the issue. Bingo ! Was I happy !

How did this ended up ? I fully documented the bug to SAP asking them to fix the issue, SAP's support agent didn't agree with me on that . . . I was furious :rage:. Can't remember if I got a fix.