I am sorry you had to go through this... I can feel your frustration. If you don't mind me asking was the container field an externally stored or within filemaker?
FYI- we have over 350 iPads using fm go and we are taking pictures as well.. I have not had any issues yet. Please let us know about your solution so we can help you..
I figured this out a while ago, wanna put it here for others...
When you import/export a database to/from fm go, you must close the go app then reopen it for the changes to take effect. If you don't restart the app, you apparently just keep working on the old version of the database but the data won't be saved.
By restarting the app after every import/export, I haven't run into this problem again.
Restarting the app fixes a number of FM GO issues that apparently persist even with iOS8 and the latest release of FM GO.
Filemaker Go doesn't close the database if you press the home button, it just suspense the database. This may be an issue by design to keep the database from becoming corrupt. Thanks for the information.
No, but double clicking Home and flicking the FM GO App up closes the App and all open files. This kind of "do over" clears a number of issues.
I've found a simple work around is to place a "Close" button or script into your db. When you "Close File - [Current File]" then the db is closed and FM Go may still go into that suspend mode but your db should save your work.
it's a bad thing. But FMGo (at least on a 16Gig device) can't be used for critical app's.
I got a medical FMGo app to controll the count of application of a medicament. This worked perfect during the whole iOS7 cycle. After the FMGo updates coming with iOS8, this FMGo app became unreliable. It works well a couple of times, then suddently nothing happens when the user clicks on 'apply' (creates a new record and counts up a counter by 1)
I lost hours of trying to debug and resolve - but the only thing that helps is wish-away the FMGo app after the app was closed. One time, the restart of the device helped. After such an intervention, the app keeps on runing well for a while... an absolutely no-go, especially eldery users can't deal with that.
Since this app runs well after a restart of fmgo, I don't believe that it's something like scripting etc. I even rewrote that app in a very simple way - no chance. I also realized that creation dates (by creating a new record) were filled with question marks - and after a restart, every thing was fine.
I got the impression that things are less worse on my 128Gig iPad...
It is clear that FM Go has issues. But there are simple inconvenient "best practices" that seem to work. Have found that transferring files to FM Go using "AirDrop" causes the file to be opened incorrectly about 50% of the times. And that working with this file in this FM Go corrupted state can cause data corruption, usually a popup stating file Can't Be Modified, because it is being Modified in another Windows occurs. If data has been modified before the popup, then data corruption likely has occurred. In any case, best practice:
1. Always close files for each session of use, ... reopening is fast enough, I use a " Quit " application button in my layouts.
2. Often reboot FM Go, and always after transferring from wherever to FM Go, ... Reboot: Double tap home button, and swipe FM Go upward. Then restart FM Go. .... rebooting is also fast, but inconvenient.
As inconvenient as this two practices are, it seems wise until FMI can FIX the issues. Getting in the habit of applying this "best practices" has eliminated much frustration, after a few 100 times, have not yet encountered an issue. .. It is not satisfactory for clients using / paying for our solutions to apply these practices, but it is what it is.
The issue you are having with AirDrop may can be explained. You need to close the database in Filemaker Go before you transfer the file using any file transfer service. (Not just AirDrop) This may explain the file corruption too because the File is open in FMGo and then AirDrop opens the file to transfer to your computer. I seen post from using with that same error message using drop box and I understand the problem was because the file wasn't being closed first.
Rouelf you are exactly right, from what I've discovered since posting the question last year.
It's a real limitation on getting non-technical types to properly use the app...
Hey Stacy, good comments. But no, applying "best practice" step 1, above, ..."always close files ....."; still after transfer to FM Go, FM Go opens in an improper state (about 50% of the times) that can result in corruption of data before the popup indicating " ... Cannot Be Modified ...." occurs. Therefore, have to apply "best practice" step 2 above, reboot FM Go always after each transfer, and otherwise reboot often.
I transfer file to FMGo all the time and I don't have to reboot. Clicking the home button does not close the databases, it puts it into hibernation. I have not had any issues as long as I close the database. I close FMGo when I'm done using it, which is the steps you call rebooting but I don't restart FMGo. I start FMGo when I need to use it. I transfer a file then I can open it with no problems.
You are right, about clicking the home button. I think we are saying the same thing, the need to close FM Go, not just quitting the solution running in FM Go (of course closing FM Go quits all open solutions). If you close FM Go as per above, then whenever you restart it is the reboot process. From what you say, and what I say we have two ways that produces no problems:
1) Close FM Go as per above, then effect transfer to FM Go, then restart FM Go (Your Process); then no problems.
2) Quit all open solutions in FM Go. with FM Go in hibernation, or not, then effect a transfer to FM Go (my process), then reboot; then no problems.
I think I like your process better, always close FM Go.