AnsweredAssumed Answered

Forcing Idle Users to Commit

Question asked by sarahs on Jan 5, 2010
Latest reply on May 11, 2016 by Mike_Mitchell


Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)


In a large new client (50 filemaker 10 windows workstations split over two physical locations, one connected via terminal server), we have run into a major inconvenience to our users - locked records caused by a user editing a record and walking away before committing. We have confirmed this is solely user caused (no missing commit records in our scripts) after extensive testing and recording. However, despite warnings of the importance of exiting records and logging out any time the computer is left unattended, the users are still forgetting often enough to make this their biggest complaint. This is a health care product and despite this being a HIPAA violation with fines starting at $10,000 for the offending employee and doctor, the users just are not making this change in their behavior. We've been looking at ways to trigger (a) auto-commit an idle user's work and if possible (b) run our internal logout script (goes to our login screen, filemaker is locked, but remains open for quick restart) if a user has been idle beyond a certain length of time.


In a previous Warning before being disconnected from FM server's idle timeout feature, the moderator TSGal recommended that:

However, you may want to look at the script step "Install OnTimer Script".  This will run a script at a specified interval.  Therefore, create a script, COMMIT, that only has the command:


Commit Records/Requests


Then, as a Startup script, have it execute:


Install OnTimer Script [ "COMMIT" ; Interval: 1800 ]


This way, the COMMIT script will run every 1800 seconds (30 minutes).  Therefore, assuming your idle timeout is set to something greater than 30 minutes, if someone walks away, the data will be saved.


I've implemented a version of this in our extremely large database solution (over 50 files, thousands of fields per file, hundreds of layouts per file) that commits the record in each file (we want to automatically unlock a record and let another workstation edit it if an idle user locks it for a certain length of time) , but our QA team noticed a huge problem with it. Namely, any user who is currently typing when it is run has the focus removed from their field. So in the middle of typing, the field suddenly loses focus and you have to click it in to start typing again. Incredibly disconcerting for a user...


I've tried recording the currently active field and return them to that field, but it does not return them to the place in the field they were and that could cause huge user input issues. Script triggers tracking how long a field has been edited and the length since the last keystroke would be impossible to implement, due to the sheer number of layouts and fields we have.


Is there any way to link the idle timeout feature on the server to run a script instead? What we would really like to do is have a user idle for x minutes prompted with a warning, then all records committed, and logged out to our internal FM login screen. Any suggestions?


We're on FM 10 in Windows - I use FM 10 Advanced, clients use FM 10. Most clients will use FM Server 10, some small clients may connect peer to peer. All use TCP/IP for sharing with no IWP or ODBC/JDBC.