This is a bug in Filemaker that I hoped had been corrected in FMGO 14. Unfortunately it looks like it is still a problem. I call it the Revert from hell because tapping a button in the message box results in another error box. You have to kill the app to get out of the loop. I think one thing you can do is to not leave a record in an uncommitted state when you exit the app.
Thanks for the feedback rgordon. Good to know that this is a known issue and I like your name for this bug — 'Revert from Hell'. Hopefully you get royalties when it gets into wider circulation.
"I think one thing you can do is to not leave a record in an uncommitted state when you exit the app."
Any suggestions on how to do this, given the iOS approach which allows the user to exit the app at any point, (by tapping the Home button) without doing anything that sets off any of FileMaker's built-in triggers?
I have added a dialog that encourages them to commit the form (my definition of commit being setting a lock field to yes) on closing the window, but my sense is that the users are still going to abandon that window regularly, without tapping any of my onscreen buttons. No buttons clicked, no triggers set off, record left uncommitted.
I can probably train my users somewhat, but short of adding a script trigger OnObjectExit - Commit Record to each of hundreds of fields in a dozen tables, is there a better way?
This is not the exact same issue from FMGo 13 the error message is different. It is similar error message. I have not seen any reported issue with that message or the other message in FMGo 14. It could be related. I guess the error message could have been updated / changed in FMGo 14. The problem from 13 is one of the reason the close button was added to FMGo 14.
It appears that the "Report an issue" is still up and running which is the best place to post about a possible bug. Report an issue . Bug Report . FileMaker Forums
If you installed a trigger on every field (which I wouldn't recommend) you still couldn't prevent the problem because all a user has to do is edit a record, leave the cursor in the field and then tap the home button. The user will exit filemaker but the trigger will not fire since the user didn't exit the field. Portals are very susceptible to problem sinces you can enter multiple rows and lose eveything if the parent record is not committed and the error occurs. As a result of this I use the following trigger for fields in a portal:
I also run triggers on checkbox, radio button and popup menu fields
In a scenario that I experience a similar error in my solution, it is possible to get out of this loop without quitting the application as follows:
1. Attempt to commit the record then choose the "Revert" option
2. Attempt to close the window... Revert error appears again
3. Choose "Revert" option again and then close the window successfully.
BUT... what do I tell my customers? Just "quit the app", as I'm not standing next to them while trying to get them to follow the steps above. I haven't tried too hard to come up with a softer error capture as yet - my customers are learning pretty quickly to ensure that they commit the record before putting the iPad down, especially after experiencing this error once or twice. Therefore, it tends to only occur a couple of times with new users.
To reduce the likelihood of experiencing this error it may also help to increase the "Auto-Lock" setting on the iPad to "Never".
I too have been experiencing this with our FileMaker Go app (14). I have several technicians on the road who get this message, and it is practically making our solution unusable. I have implemented a few things like script triggers on certain imperative fields and also a 'button' on the layout to 'manually force commit' any unsaved data. Our technicians have been trying this, but are still receiving the same error.
I really could use a complete solution to this error, if anyone has any clues I'd appreciate it.
Here is an idea. Create a new table with one global field. When a user pauses there work have them tap a button that sets the layout name into the global and then takes them to a layout from the new table with a big resume button. Switching to this layout will commit all records. When they want to continue working they tap the Resume button which takes them back to the layout stored in the global field.
Thanks! That's a very good idea. Conceptually I understand it, although I'm hoping I have the expertise to implement it!