For the "B64" container fields, what should our recommended storage options on those be? Without paying attention, I left it on the default of "Indexing / All" which was obviously a huge problem, but should I have "Do not store calculation results" checked? The reason I ask is my 2Gb DB doubled in size after adding these fields. 

Ryan --

 

To keep the file size down, I recommend using un-stored calculations. However, you'll take a performance hit, as FileMaker will need to handle the encoding on the fly. So it's a bit of a trade-off.

 

There are some additional suggestions regarding the handling of containers here:

http://fmeasysync.com/docs-easysync-integration/

 

-- Tim

Yep. I am already on board with the suggestions in the handling of containers. I've already change my users to use the FM camera on a Large or lower resolution.

 

I think I would rather have the performance hit at time of sync than have the database double in size on a device with limited space.

Tim,

You mention this issue on your troubleshooting page:

 

Some synced containers are being corrupted. Why?
One possible explanation is that the values in the containers are being stored using FileMaker's "compress" option. There is a known issue with FileMaker's Base64 encoding function, where the function does not first decompress a container's contents prior to encoding. To avoid this problem, do not use compressed containers.

Note: This issue also applies to secure, external containers. FileMaker is not decrypting the containers before Base64 encoding them. As a result, decoding those values returns incorrect values.

 

Has there been any fixes for this? Currently, we are not using external storage at all on the hosted file because of this (secured or unsecured). Wim has strongly suggested not using non-secure external storage.

As far as I know, there is still no fix for this one.

 

-- Tim

Thanks, Tim. If you have any creative ideas for managing lots of image data, please feel free to share! ;-)

 

We cannot leave all our images in this table. The least we can do is break it off into a separate file, but we're thinking beyond that to perhaps Amazon Web Services. However, we do have to remember our FMGo clients.