For different reasons in one of our systems, we instituted something similar and in our particular case we found that most users who wanted this feature changed their mind after getting it (primariliy the "auto" commit of record if no response). It turns out they would be away from their desk perhaps working on the issue with the record (or on a smoking break ) and by the time they returned more than not didn't want to commit it so they'd have to go "fix" it. This client's management finally realized the issue was more of an administrative or people issue than a system issue and we removed the feature and the staff was just trained and reminded that they had the responsibility to finish the transaction one way or another.
Probably doesn't help you much for your needs but that was our experience.
I'm not sure which databases you have previously used but FileMaker automatically commits records.
From the FileMaker manual:
Committing data in records
Unlike most word processing applications, FileMaker Pro saves your data as you work. This is called committing data. Data is committed when you:
select another record
click anywhere outside of the current field
Windows: press Enter on the numeric keypad, or Ctrl+Enter on computers without a numeric keypad
Mac OS: press Enter (not Return)
switch to another mode
Hope this helps.
Thanks for the details, but we are talking about when a user is stuck on step #2. Thanks though.
Having used FileMaker for ten years, I've not experienced this issue with my users. However, I try to follow best practices and never make programming changes when folks are actively using the database. I also use a separation model, so I rarely make any changes in the data file schema.
So, if your users are getting distrtacted while entering data in a field and you want a committed record, it appears that the only way to insure that is to use the OnObjectModify script trigger. However, that would likely cause performance issue with the database. I'm also not sure that this will help your issue as FileMaker locks the record as long as any user has it open. Good luck.
I encounter these now about once a week with our network of users, usually when I need to edit in Define Fields, but one or more users has an uncommitted record in taht table.
I consider it a people/training issue, and just have to track down the offending clients. More often than not, the user is busy in another program, away from their desk, or even just in another window -- usually completely unaware they have a locked record which is uncommitted to the server.
I always remind them that their edits to that record have not been committed and would be lost if their session times out. Gradually they are learning that their work is at risk, so they make this mistake a little less often than they did a couple of years ago, when it was almost daily.
Running a looping script on a timer creates some serious client overhead in a multi-file/window system. I opted for the slow process of retraining -- partially successful.
Thanks for the response Stephen. I am mulling this one over for now, I think I'll test implement a script trigger just to see how it affects the speed. Will let you know how it goes.
Along this line, you know the error you get in Define Fields when someone is working in a record? It gives the "Send Message" option to alert the user...have you ever tried using that? I used to think it was a great feature, until I realized that the offender's Filemaker doesn't seem to receive the message most of the time. I haven't checked in a while since I gave up on it. Wondering if it's a common problem, or just me.
No, it's not just you. I found this too, and it usually bit when a user had switched to another window, leaving an uncommitted record in the first window. This was in a system that had started life in FileMaker v5 or earlier. Thankfully it was a small company, so sneaker-netting to the relevant desk was not a problem...
“Sneaker-netting”, I really like that! Good one.