When using FileMaker's new remote containers - and the databases is hosted here are a few caveats that you may wish to employ...

Each container field in each table must be setup which should include the serial number of the record you are on (either a sequential or the UUID)

This way EACH image you add to the table on the back end the server will create a directory for this file image.

[hosted path]/TableName/ContainerField/1234/myfile.jpg

[hosted path]/TableName/ContainerField/1235/myfile.jpg

If you don't include this ID into the path and you add the SAME image or file to multiple records on the server you will only have ONE copy of this binary object.

If the you add a different file but named the same on import the server will rename the appending a _# to the file name.

-

Also if you have to work with the file locally (download from the server) you may have to go to each remotely stored container in each table and un check the option to store remotely and then transfer the binary data back in to the database so that it can be downloaded.

then reverse this process once you re-host the file

Also if you have to work with the file locally (download from the server) you may have to go to each remotely stored container in each table and un check the option to store remotely and then transfer the binary data back in to the database so that it can be downloaded.

then reverse this process once you re-host the file

Not so.. if you download or upload using the FMS admin console feature your Remote Container data files will be kept intact and bundled with the upload and download.

Also the paths in your example indicate that you would turn OFF the secure option. Keep in mind that remote containers are not a file management option in the sense that you should be able to interact with those files from outside FM. FM now keeps them outside of the core FM file if you choose to but really we have to think about them as still *inside* FM. Container data inside a FM file is not visible to us or anyone else's prying eyes except by going through the security layer of opening the FM solution.

If you turn off the secure storage option for remote containers you are giving up that security. Anyone with access to the server (or god forbid, a share you've enabled) will now be able to see the files that you have stored in your containers.

Keep in mind that remote containers are not a file management option in the sense that you should be able to interact with those files from outside FM. FM now keeps them outside of the core FM file if you choose to but really we have to think about them as still *inside* FM.

Yes, that was a conclusion that I made after reading one of the docs that you and Mr Blackwell wrote. In the initial NDA briefings I was thinking that it could be treated rather like a shared volume. Glad I sorted that out. :D

But it is true about FMS keeping one instance of a file, and somehow in FMP's index it links a file to multiple records, and that the file names are modified on the server if there are existing files in the directory.

The secure option avoids this.

However i just tried to download a database is hosted and thru the console i turned off the database and asked it to download it and all i got was the database without the binary data each container had missing link.

Keep in mind that remote containers are not a file management option in the sense that you should be able to interact with those files from outside FM. FM now keeps them outside of the core FM file if you choose to but really we have to think about them as still *inside* FM.

Maybe a simplistic view, and I realise this isn't the design intention, but, what if we *DO* interact with those files outside FM? (assuming we have decent security on our server right?).

Currently I use SuperContainer to export FM container JPEG images taken using FM GO, resize the images to 1024pixels along the longest edge, then re-import it. I think I can now do that with FM12 native external containers and a OS-level script (eg. sips).

I can think of various other scenarios where (carefully) manipulating container field content outside of FM would be useful and I don't think this will cause issues for FM.

Or will it?

I can think of various other scenarios where (carefully) manipulating container field content outside of FM would be useful and I don't think this will cause issues for FM.

Or will it?

Too early to say. Given that we now for sure that the RC feature was not built for what you are describing, I would stick with SuperContainer. I would not build a solution around a key concept that may completely break that solution.

Too many horror stories on this forum about people who have jumped head first int 12 without a solid understanding and/or testing.

For RC specific: I would leave the secure storage option on and that would in effect not allow the functionality that you have in mind...