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.
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.
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.