Hi Mathew, What version of FM Go are you using? It was crashing when taking a photo from a container field but it was fixed in v1.2.1 and v1.2.2.
Currently on 1.2.2
Hi Matthew Mackay:
Thanks for posting.
From your description of the issue, it’s possible the issue is database corruption. I have a few questions regarding your solution.
What is the file size of your database?
How many records are in your database?
How many images are in the solution?
Have you tried creating a compacted copy of your database?
The next test to try is seeing if a new database file also crashes in FileMaker Go. Create a new database file in FileMaker Pro. In this new database, add a few records which have container fields for your images. Upload the new file to your device, and then try taking photos and see if you can get FileMaker Go to crash. Let me know if any crashes occur in the new file.
The file starts at 5MB, after the full inventory has been completed it can reach up to about 10MB at most. We set the iPad camera to 'small' for capturing the images to limit the size of the database.
There are about 6000 records held within the database.
The number of images depends on the size of the property, it would probably average out at about 70 photos.
I've tried a compacted and non compacted version.
I could try creating a new database but it wouldn't really help with the problem. I'm not saying it's Filemaker Go that's the problem, it probably is something in my solution but as my solution has got quite complex, I need to try and find what's causing these issues in the current database.
If the issue does not occur in a new database, it could indicate corruption within your database solution. Since you have tried a compacted copy, the next steps are trying a recovery on your database. Under the file menu in FileMaker is the option “Recover…” which will run a recovery on the file you select. Let recovery run and see if it finds any bad blocks within your database. Afterwards, test if the recovered file experiences crashing in FileMaker Go. It’s not advised to keep using a recovered database though. The recovery is meant for recovering the records to add into a new database file.
Do you have any backups of your database? If you do, you should test if any of your backup’s crash in FileMaker Go. A backup that functions properly can have the most recent records imported into it from the corrupted file. Let me know if these suggestions help.
It takes a bit of doing to create a database in Filemaker that self-destructs but I can from experience tell you that it can be done.
Did you specificaly test and debug your database on your GO ios as you created it noting what works and what doesn't work or did you only work in Pro and then throw it at Go without testing it?
Created an open URL step in PRO using the Ethernet IP Address on my laptop and it worked great, well it failed nicely, but on GO it brought up a black screen and GO had to be restarted. I am a lifetime member of the Application Busters Guild, "We Can Crash Any File!".
I would suggest that when working with Go you use a related file to store the pictures and that you proceed as quietly as possible in that file.
Go To Parent Record
Set ID into $_ID
Go to Photo Table Form layout
Sset linking field to $_ID
Now all you need to do is touch the container field to take the picture, or something like that. Then save the record again.
This works nicely and you notice there is NO complexity, NO custom this or that, NO triggers... NADA
Remember, you only have a smidgen of RAM to work in and GO runs slower than a desktop.
Heck, if this were really important financially to me I would only use a small, lightweight file to store the pictures and then import them at home. Or even, gasp, use the built in app to take the pictures and save them to the IOS device and then work with them at home.
Go works great but you can crash it...