5 Replies Latest reply on Feb 18, 2014 9:18 PM by rgordon

    FMGo13 and connection loss


      I have been following a discussion on the FM public forum. It revolves around what happens when a mobile device loses the connection ad reconnects.


      The records sometimes do not commit and reverting the record can cause big issues. I have had this happen in FM12 when ipads go to sleep while viewing a record. If the record is modified by another user and the ipad tries to reconnect it is a mess.


      Others seem to have reported more serious issues with FMGo13 in connection to this problem. Loss of large amounts of data.


      Is this a real issue for most developers? How are you handling it?

        • 1. Re: FMGo13 and connection loss

          For applications where connection loss is an issue, redesigning the application to run without a persistent connection to the server with the assistance of a tool like GoZync is the first answer that comes to mind.

          • 2. Re: FMGo13 and connection loss

            It seems that the connection loss happens all the time unless the device is on a wifi connection and set to never sleep. Connection loss is always an issue.


            What you are suggesting is that mobile devices will not ever properly work unless something like gozync is used.


            I looked at gozync and it looks clunky. It would be great for long distance access for info that does not change rapidly with access to many users.


            In my case we are used to having ios devices connected over wifi and need the speed of having data updated quickly. Needing a sync plugin in a local network environment is not what we expected when FM said it works for mobile devices.


            The point that has been made is that  FM should be addressing this connection issue as an internal fix.

            • 3. Re: FMGo13 and connection loss

              I think this is a huge problem.  In a nutshell the problem is if fmgo gets disconnected from the network, when it tries to reconnect, FM server doesn't handle the disconnect well.  When fmgo reconnects, FM server thinks there are two sessions working on the same record.  You end up getting the dreaded Revert message.  At a minimum, you'll lose any uncommitted records and possible a whole found set of records.  There are ways to minimize the impact.  In my testing I found the iPad going to sleep was not the problem.  The real problem was wifi disconnects that might happen when the iPad is asleep.

              • 4. Re: FMGo13 and connection loss

                I am not suggesting that mobile devices will not ever work properly unless something like GoZync is used. I have deployed FileMaker Go applications running on cellular data networks on devices that sleep without running into the sorts of problems you describe — at DevCon to a large audience of other developers, no less.


                Perhaps there's room for FileMaker to improve the handling of intermittent connections from FileMaker Go to Server over poor quality networks, but that's hardly the most expedient solution. By all means, ask for the improvement; but don't wait for it.


                Is there any room in your application to limit the opportunities users have to leave records open? iOS user interface idioms allow much greater latitude for distinguishing between very different "view" and "edit" modes in applications, which developers can take advantage of to keep records closed as much as possible. The OnRecordOpen trigger can be particularly helpful for keeping users from opening records on layouts where you don't intend for them to, by exiting with a False (0) script result, thereby canceling the action of opening the record. Data entry on iOS works best when it's quickly in-and-out, not dawdling. This does not removing the possibility of encountering the issue you describe, but it should reduce the frequency, which is better than nothing.

                • 5. Re: FMGo13 and connection loss

                  One of the issues is the way most users interact with their iPad isn't the best way to interact with a FileMaker database.  Most user will simple tap their home button or close their cover when they are finished. I've minimized this problem by using Get(RecordOpenState) in script triggers to commit records.  This is especially helpful if you are entering data into a portal.