1 2 Previous Next 15 Replies Latest reply on Mar 1, 2015 11:09 PM by Markus Schneider

    FMGO reverting issue



      FMGO reverting issue


      Every few days but with no identifiable pattern,  FMGO users get this error.

      "Error:  Your record was changes cannot be saved because this record was modified by another user while you were disconnected.    Revert or Cancel"

      The record shown is the user table and the only record found is the one matching the account log in name.  I cannot figure out who would be modifying that record while this user is disconnected.  

      It seems that no matter which option you choose, It is very difficult to get out of this loop.    Is there anything I can do to prevent this error in the first place?  or is there a script I can write to clear the error?  Thanks.

        • 1. Re: FMGO reverting issue

          Eric Lindholm:

          Thank you for your post.

          From your post, it is difficult to determine the cause of the issue.

          The host will continue to check for a client connection for approximately two minutes.  If no connection is found, then the host will disconnect the user.  Do you know how long the client was disconnected?

          It's possible FileMaker Go has gotten into an unknown state.  The next time this occurs, exit FileMaker Go, relaunch FileMaker Go  and open the file.  See if the client is able to now make changes.

          Keep me updated with any progress.

          FileMaker, Inc.

          • 2. Re: FMGO reverting issue

            the user is always disconnected for longer than two minutes when the error occurs.

            When this happens, the user tries to exit but the error pops but again when they try to exit.

            also, when the user tries to force quit, the connection is re established and the error persists.

            • 3. Re: FMGO reverting issue

              Eric Lindholm:

              What is the value of fmreauthenticate extended privilege?

              If a client quits out of FileMaker Go, and within 10 seconds launches FileMaker Go, the connection will be re-established to the last setting.  Have the client exit FileMaker Go, and wait more than 10 seconds before relaunching so the previous connection is severed.

              FileMaker, Inc.

              • 4. Re: FMGO reverting issue

                Eric Lindholm:

                One of the other support technicians (TSFalcon) believes the disconnect has put FileMaker Go into a bad state, and suggest you use the workaround script provided by forum user "PhilModJunk" at:

                Record cannot be modified in this window because it is already being modified in another window

                Although this won't detect what is causing the issue, it will detect there a problem with the network and prompt the client for a restart.

                FileMaker, Inc.

                • 5. Re: FMGO reverting issue

                  Sounds good.  I am just having trouble figuring out what triggers this script in the example file provided.  

                  • 6. Re: FMGO reverting issue

                    My script is set to run "onFIrstWindowOpen". I consider the fact that this script has been 100% effective on multiple files over extended usage is itself a potential clue as this "bad state" has only occurred at the point in time that the file opens.

                    But I'm not currently running files as FM GO clients of a hosted database, so this state might occur in that scenario at points in time other than when the file is first opened.

                    • 7. Re: FMGO reverting issue

                      Phil's script will work on detecting when the conditions are right for a lot of the FmGo problems to occur.   Restarting the app will reset these conditions.  Unfortunately your problem is a different problem and the script will not work. Filemaker server is not releasing the record lock on the disconnect, and when fmgo tries to reconnect  the server thinks that somebody else is trying to modify the record. The best thing to do is to not click the Revert button.  Double tap the home button and kill the App. This problem can also be very destructive to records.  You can easily reproduce this problem by leaving a record uncommitted and then walk away from your wifi zone so that you are no longer connected to the wifi.  When you come back to your wifi zone, Fmgo will try to reconnect and the revert error will occur.  Here are some things that I do to prevent this: 

                      1. Run scripts to frequently commit records. Try to avoid having uncommitted records, especially in portals 

                      2. Teach users to close the files when they are finished

                      3. Tell users to never just close the cover on an iPad or to to just put the ipad/iPhone to sleep

                      4. Never tap the Revert button or you will will end up in the Revert loop from hell  


                      • 8. Re: FMGO reverting issue

                        RGordon, I think you are right. I've had this issue before and can trace it back to when I was doing a lot of development on my FM GO Files--the one time that I was hosting the file from my LapTop and using my phone as the client in order to quickly test the changes before copying over the file...

                        • 9. Re: FMGO reverting issue
                          Markus Schneider

                          Both of the tasks #2 and #3 will help! But all of them are non-standard-iOS.. Quitting a file is not easy to teach when users are elderey people (there are some medical apps around..).

                          In principle, those issues have to be fixed soon - and leeds to another feature request: QUIT, let FMGo have a really QUIT button (I'm aware that this is Apple's part of the game - but maybe a friendly call (or walk over..) might help here). But as mentioned several times: I'm really afraid that nobody at FMI is really working on an iOS device (with or without FMGo - just check this forum software here when on an iPad...)

                          I'm answering here because I'm pretty sure that it makes no sense when users 'patch' processes that are really common, just because one single app' can't deal with something

                          Those problems are since iOS8, in my gut feeling occur more often on devices with less RAM


                          • 10. Re: FMGO reverting issue

                            I don't think it is Ram related, I understand (Google search)  that all ios devices have 1GB of ram except the iPad Air 2 which has 2GB of ram.   The disk storage is not RAM and should not effect software running, unless the disk is full, which Apple may be using some kind of cache, which this cache may be based on the HD size.   If it is Ram related then there is nothing that Filemaker can do.  I totally agree that something needs to be done.  Maybe these issue will be address and fixed in the next version of Filemaker. 

                            • 11. Re: FMGO reverting issue

                              Markus, I think you are on the right track with the quit button / quit function.   I believe this is the cause of many of the issue Go is having.  I don't think Go is able to resume correctly from a hibernate state. 

                              • 12. Re: FMGO reverting issue

                                I also don't think this specific issue is Ram related but I do think the issues that Phil's script detects are Ram related.  

                                • 13. Re: FMGO reverting issue
                                  Markus Schneider

                                  Sounds logical - but I got a 16GB iPhone 5s and a 128GB iPad Air2

                                  - I have to restart the iPhone very often (actually I 'swipe-quit' FMGo after every use)

                                  - I leave the iPad running for weeks, no issue (well... almost.. sometimes, gestures won't work properly anymore (not just FMGo) - then I restart the device)

                                  And yes... the iPhone did even not have enough space for the first update to iOS8 but in the meanwhile there are 2GB free. The FMGo apps are not identical, the one in daily use on the iPad is much more complex, the iPhone FMGo app is more or less a counter - and does nothing after a couple of days.. it's a script that adds a record in a table, commits the record and goes to a dashboard layout that has a counter for the created records.

                                  After a swipe-quit, it works perfect again - for a couple of days

                                  It can be something different, but it's annoying in every case. Both devices are working perfect besides of those issues - and I'm using both every day

                                  • 14. Re: FMGO reverting issue

                                    The hard drive getting full can cause issues. The Ram (1Gb to 2 Gb) is the memory that is used to run the software the Harddrive (8gb to 128gb)  is the memory to store the software.    Software is loaded from the Harddrive into the Ram. Ram is cleared when the device is turned off, the Harddrive is not.

                                     I don't really think it is a ram issue per se, more of a memory management issue.  In other words how Filemaker Go handles the memory it uses.  I really don't think increasing the Ram will fix the issue.   That is why I think the quit function may help and why rebooting FM Go helps, because it is clearing the memory that Go is using.  Filemaker Go is not using all the Ram on the unit, I assume the iOS handles this operation.  I also believe when Go hibernates, there may be  issues with Go trying to commit records and or Filemaker trying to re-login to the network / database. 

                                    I guess it is all speculation.  I just hope they get the issues fixed. 

                                    1 2 Previous Next