Home / Blog / Transitioning From SuperContainer to FMP12 Remote Containers – It’s easier than you think!

Transitioning From SuperContainer to FMP12 Remote Containers – It’s easier than you think!

I recently tackled transitioning a FileMaker 11 system using SuperContainer to a FileMaker 12 system using remote containers. I remember worrying I may have to spend a few long nights moving the files from SuperContainer to remote containers. However, thanks to the tip from my very knowledageble coworker, Beth Bennett, I discovered that it is possible to script the transfer process! Boy was I relieved. I’ll show you how: Let’s say you have a record for every SuperContainer file you’ve uploaded, and you want to keep that table and it’s records, but now you want to use remote containers.

  1. Be sure you have the SuperContainer companion plugin installed on your machine if you don’t already.
  2. If you don’t have this already, create a field in your table that is the relative path for each SuperContainer file, but doesn’t contian the base path. For example, your full path may be something like this:
http://host:8020/SuperContainer/Files/Legal/Upload23

Therefore, your base URL would this:

http://host:8020/SuperContainer/Files

Add your relative URL would be this:

Legal/Upload23

You need a field in your table that contains only the relative path.

  1. You will need to create two container fields in the table: one that will replace the SuperContainer, and a temporary one.  Make sure you set both of them up to use remote storage.
  2. Now create a script to do all the heavy lifting. The meat of the script will set the base URL, set the temp container to what is currently in SuperContainer, export that container to a temp folder, and then import it into your real remote storage container as interactive. The script will look something like this:
Screenshot of the script
  1. Run your script! (Test it out with a small sample first).
  2. When you’ve finished transferring all the files, then you can delete the temp container you created.

And that’s pretty much it! Pretty easy right? You may be wondering why I did some things the way I did. Here are some logic behind the script:

Question #1: Why are you importing the file twice? Haven’t you finished after the first import into the container field?

Answer: You are done, if you don’t mind that the file isn’t interactive. If you want the file to be interactive, then you have to import it with the Insert File script step and the “Display content of file when possible” option selected. Since that script step doesn’t allow a URL as an import source, (it only allows a file path), then you have to import it twice.

Question # 2: Why use 2 containers? Why not just use one container and replace itself?

Answer: That’s how I orginally wrote this script. I then realized after testing that the files were saved as FileName.pdf and FileName_1.pdf, because I imported the file name twice into the same location (once through the SuperContainer GetContainer function and once through the Insert File Function).  By having a separate temp container, I don’t have to worry about storing the file twice in the same place, therefore keeping the integrity of the file name in the final product.

Question #3: What is the logic behind getting the file name?

Answer: When you get a container field as text, this is what it looks like:

remote:About Stacks.pdf
size:612,792
JPEG:RemoteContainer/container/12/About Stacks.jpg
PDF :RemoteContainer/container/12/About Stacks.pdf

I just want the file name. So I get the first value of that value list, replace the “remote:” (which is 7 characters) with nothing, and then that leaves me with the file name.

I hope this is helpful for anyone who needs it! If anyone has any questions or suggestions, please feel free to comment below!

3 thoughts on “Transitioning From SuperContainer to FMP12 Remote Containers – It’s easier than you think!”

  1. This is so helpful! In FileMaker 13, using your model, we built a similar script to move image files. Every now and then, maybe one in 50 files, our script would return the error, “Container fields cannot be exported.” What might cause this?

  2. Makah Encarnacao

    Hi Holly, 

    Some inital thoughts are:

    1. -File type might not be recognized or file extension is missing
    2. -Lag from the plugin could cause some issues. Try adding a pause script step after the export calls to make sure the actions are complete before the script keeps running.

    Let me know if neither of these fix the issue.

Leave a Comment

Your email address will not be published. Required fields are marked *