to see if this is another manifestation of the "record cannot be modified..." bug (Which I refer to as the GetField bug...), try this test the next time you get that error message:
Double click the home button.
Flick the FileMaker Go app up to close the app.
Reopen the FM GO app.
This temporarily clears the error condition of the "record cannot be modified..." but so if this is another example of the same, this same action should work here as well.
(I've been able to use the fact that getField will return a null value when it should not return null as a test in a start up script I put into my FM Go files. If I can get the file open without this script detecting an error, it works without issue until I close it.)
I've done that as a work around though eventually, some record gets corrupted and I have to recover, import, etc.
I guess I'd really like to know how to figure out if it's my scripting that is causing the corruption somehow or if it's the bug. I suspect it's the bug only because when the index gets corrupted, it always happens out in the field when the cell signal changes up.
Thank you for your posts.
It is difficult to determine where the issue lies. To help narrow down the possible causes, copy the FreedomCar.fmp12 file to your iOS device and work with it locally. See if you still get the "damaged" error.
Also, if the "cell signal changes up", that can definitely affect the database file, especially if there are updates occurring to the hosted file during the time the cell signal is lost.
What I've discovered so far is that there is something going on that is perhaps "damaged". It just doesn't show up as anything for awhile until a record disappears. Before this, you can run a consistency check, recover the data but nothing is there and message will still come up at random intervals. I have to wait until there is visible damage before fixing it (aka.. a record with ?marks) . FYI.. this happens every 2-4 weeks. There has to be away to input information to the server for over a cell tower without damaging the database. Working from a local copy is really impossible because we have too many changes through out the day and those out in the field would constantly be uploading a fresh copy. Is there a way to "hold" information on the client side before committing the record? [Currently, all data is "auto-committed".] How do I know the cell signal is bad for uploading the data? Is there a signal strength you would recommend not sending information over? Have you all tested this in the field?
In the meantime, I'll pull a "broken" version and try it out on an ipad.
FileMaker Go will not detect signal strength. It is binary. That is, the connection is either on or off.
The only way to "hold" information on the client side would be in a local file. One possible option is when you have found a specific record you want to update, it downloads that information into a local file. This would hold the data until you are ready to update. That is, make the changes in the local file, and then execute a script (possibly by a button) that updates the data from the local file to the hosted file. Clear out the local file, and continue on.