3 Replies Latest reply on Jul 25, 2014 3:46 PM by philmodjunk

    FMGO fails to commit data back to local file



      FMGO fails to commit data back to local file


      FileMaker Go


      FM GO 13.0.4

      Operating system version

      iOS 7.1.2

      Description of the issue

      This is an ephemeral issue. you will not be able to reproduce unless you get lucky.

      I added a text field to a popover and formatted it as a drop down list with a simple custom values value list of 4 values.

      I opened the popover and selected value from the list and saw it appear in the field. I then found that when I copied the file to my computer and opened it that this field was blank on the record where I had made this edit. I selected the value using FileMaker Pro Advanced and copied the file back to the iPhone where I then saw the selected value appear for that record.

      I then experimented further and found that if I selected a value on a record where the field was empty, I could close and reopen the popover and see a flash as the text field cleared instead of displaying the previously selected value.

      After a great deal of testing, opening, closing the file, copying it back and forth to/from a computer, I used the home button to close and re-open the FileMaker App. I could then select a value in this value list and see the value retained when I re-opened the file or re-opened the popover.

      The file has not shown this issue since the restart of the Go App.

      This is the third bug encountered in the process of creating one very simple solution with very few features. :(

        • 1. Re: FMGO fails to commit data back to local file


               This issue has now repeated in this file. In this case, I attempted to select a different value from the current value shown in the field, only to find the original value when I re-opened the popover. As I continued to test the interface, a previously reported error message appeared that the record could not be modified because it was open in another window--even though only one window was open at the time.

               There appears to be some commonality between the three issues that I have reported just from this one simple database project:

               Commit Records and the record locking management software associated with it.

               It seems that under certain circumstances, FileMaker Go fails to commit data from the interface back to the file and thus fails to close records that have been opened for editing.

          • 2. Re: FMGO fails to commit data back to local file


                 Thank you for your post.

                 I am unable to replicate the issue.  I have tried several different ways, including making the popover expand into another part section.  The file I have includes a text field in the Body, and another text field formatted as a drop-down list in a popover.  If you have an example file that tends to encounter the issue frequently, please send in a clone of the file so I can work with it.

                 FileMaker, Inc.

            • 3. Re: FMGO fails to commit data back to local file

                   To repeat:


                        This is an ephemeral issue. you will not be able to reproduce unless you get lucky.

                   I don't think the fact that the field was in a popover is a factor as I've seen FM GO fail to commit data under different circumstances where no popover was involved. In the very same file, I set up a debug feature that appended text to a global text field inserting relevant field, variable values and the name of the script as a way to track down a different issue (The getfield returns null value issue) and discovered that the global field's text wasn't being retained. When I restarted the GO App, data could then be committed and GetField started returning the correct value.

                   The global field was not in a popover and was not being modified by anything but a setfield command. I'd switch to the debug layout and see the data, then close and re-open the file and see it disappear. The file was local to my iOS device or I would have thought I was seeing typical global field behavior for a client of a hosted database. Once I spotted the fact that the global field was not retaining data, I found that other fields were not retaining recent edits as well.