Thank you for your post.
Please send in the "small demo file that reproduced the bug". I will work with it here until it fails. Any other information you can provide about the layout, fields being accessed, how long FileMaker Go was running before the error occurred, etc., may be helpful.
This was a brand new, minutes old file that was reproducing the error. I know that there's an ongoing hypothesis that an issue develops when either FileMaker GO or the database file is open for "an extended period of time", but this does not match my experiences with unstable FM GO behavior.
The demo file can be downloaded from here: https://dl.dropboxusercontent.com/u/78737945/GetFieldGoBug2.fmp12
The single layout in this file is so simple, I don't think that I need explain anything.
On the almost bright side, I think that I can use GetField in an opener script to test for this issue and pop up a warning message to restart FileMaker Go. I find that I don't even have to close the file, just restart the app and watch the open file pop back open, but now works.
This appears to be another part of the issue I reported a long time ago and again just recently that FM GO can fail to commit data back to the file. I saw that happen at the same time I was getting null results from GetField.
I've added a new script that appears to be successfully identifying the "state" that FM GO drops into when this issue arises:
Show All Records
If [ not Get ( FoundCount ) // no records in table ]
If [ IsEmpty ( GetField ( GetFieldName ( Data::__pkDataID ) ) ) // BUG!!!! ]
Show Custom Dialog [ Title: "BUG Detected!"; Message: "Please restart the FM GO App to clear this error condition."; Default Button: “OK”, Commit: “Yes”; Button 2: “How?”, Commit: “No” ]
If [ Get ( LastMessageChoice ) = 2 // "How?" was clicked ]
Show Custom Dialog [ Message: "Double Click Home Button. Flick FM GO App up. Then re-open FM Go."; Default Button: “OK”, Commit: “Yes” ]
I will be interested to see if this message pops up for the other FM GO Issues that I've reported or not.
And I've found that when this dialog pops up on opening the file, I can leave the file open, restart the FM GO app and the file reopens automatically to where I left off (but with popovers closed) and the file now functions without issue...
I have downloaded your file, and I have sent it to our Development and Testing departments, along with your additional script and notes, for review. When I receive any feedback, I will let you know.
In the meantime, I have been putting this script into more and more of my files. So far, it has been 100% successful in identifying the "bug state" at the time that the file opens and enabling me to quickly get on with using the system. I don't even close the file, I just restart FM Go and when I relaunch the app, it re-opens the file for me.
The next time that a file identifies this "bug state", if I am not rushed for time, I plan to make a series of tests to try and nail down some suspected commonalities between several different issue reports that I and others have posted.
Since you can't reproduce and yet it happens pretty often for me, I wonder if this issue is hardware specific. I'm testing this on an iPhone 4S, if you are using an iPhone 5 or other device with the newer, faster processor to check this, that may be why you have been unable to reproduce.
After all, we've already identified one other bug that is iOS processor specific so this one might be as well.
Ok, just had the script trap this error when opening the DatePickerDemo file and I ran the following tests:
I opened two other files that also have versions of this same "onFirstWindowOpen" performed script and they each also identified this error state and displayed a message to restart the app.
In each case, I then ignored the message and tried to use the files. In the second file that I opened, I got the now familiar and dreaded "This record cannot be modified because it is already open in another window" error message.
The third file (SoupInventory, you have an older copy of this from me) showed empty global fields that should not be empty. (However, a check of the script that sets these global fields reveals that GetField is used in the calculated result parameter so this appears to simply be another case of getField returning null.)
In the DatePicker file, I used the iOS date picker (rather than the one I created for the demo) to modify a date in a date field. I then closed and re-opened the file only to find that the change that I made to the date field was never committed--the original value in the field was still there.
This strongly suggests the following inferences:
It's a "state" that the app gets trapped in that is not specific to the file.
The "this record cannot be modified...", changes not being committed, and getField returning null issue reports are all reporting different symptoms of the same unresolved issue.