A customer experiences problems while shutting down a database: after he closes the database using the console, some users are still able to connect. Existing users get the message asking them to close the file(s) they are working on, but some users keep on reconnecting, with success.

The files show the status 'closing' in the console.

Could this be a communication problem between the console and the server? Or are there other possible causes?

It's regular FMPA clients (13 and 14), no WebDirect. Some (but not all) are Robot PC's, performing a timed 'watchdog' process.

FMS13 on WindowsServer 2008R2.

HEH

 

The file is still available until fully closed. The new connections should also get the message as the file closes.

Well, I have tried this on my development server and this is what I observed:

1 User A connects to file X

2 The database server is shut down with a grace period of 5 minutes

3 User A gets a request to close the file. He can click 'Cancel', ofcourse, but then gets another message and eventually he will be force logged off.

4 User B tries to connect after (2) and will get a message that the file is not found (server unavailable).

This is correct behavior ofcourse, because allowing any new connections during shutdown only complicates the process and could result in loss of data.

 

 

One of the typical ways to solve this by setting the connections limit to 0, then close the files...

Yes, but then users lose whatever is in their local cache. If there is an opportunity to keep the loss at a minimum, I' d prefer that.

I have searched through various manuals, the FMS Help files and white papers on the subject, but I couldn't find any details about the 'close database' command. Other than the syntax and options.

 

The Close Database first issues a Disconnect Users then closes the databases when it is able to.

It is described in the Help file (p 106): https://fmhelp.filemaker.com/docs/14/en/fms14_help.pdf

I looked into the Access Log, and observed the following.

- a user opens a connection from a particular workstation: this is written in the log with a code= 638. He then opens a database (code=94).

- when that user terminates his session, what normally would appear in the log is a code=98 (close database) followed by a code=22 (close session). Log entries 22 and 98 somtimes appear in reverse order, probably because FMS caches them before writing to the log. I guess that's not a big deal.

What worries me, is that often multiple 638 events (opening the connection) and 94 events are written without any 22 and 98 events at all. Why is this happening? Does it point to network or hardware errors or is FMS somehow unable / too busy to write events to the log? I would expect every session  to be logged by a 638 event followed by a 22 event, but this is not the case.