Hi,

I've Googled and read, but given the "Preserve external container storage” option available now in in 13.v2, it seemed many recommended protocols were outdated.

The setup:

• Separation Model both UI and data, hosted with FMS12. Replacing both files time.
• FMS12 (yep, still not updated to FMS13 - working with IT to do so)
• Clients are FM13
• Migration script (imports) written and ready to go.

So, can someone please list the steps needed to replace a file on a FMS12 that has secure external containers? Should I have FMS13v2 installed on the FMS12 box and run the migration locally (via Teamviewer)? I usually copy off a backup to DropBox and do the updates on my iMac and then rehost. Is this still possible without breaking links?

-Barbara

Yikes, no one? Oh, Wim...where are you?

A couple of choices...

1) best practice: keep the container fields in a separate file, 1x1 related to the records they belong to somewhere else but treat the container file as the ultimate data separation file.  Nothing in there but the foreign key and the container field, nothing else.  That will hopefully allow you to not have to migrate data in and out of that file at all.  Like with all data separation it does only work if you don't have to change the schema

2) do a "copy as self-contained" before you migrate data.  And then afterwards change the container fields back to external storage when you deploy.  This may take a very long time if you have a lot of external assets...

 

quick side note: after you pull the files down from FMS, which you need to do for the "save as self-contained", create a new record and insert something in a container.  Then see where it puts it.  Typically the folder hierarchy is off a little between a hosted file and a local file.  So you may have to move the file folders up or down a level before you attempt the "save as"

So, the "Preserve external container storage” isn't all that helpful?

I think as part of this upgrade, I'll take the opportunity to separate the Documents table into its own file.

If there are gotcha's that you're aware of separating out the container table, pls let me know.

I'll follow (2) for the migration. Luckily, not a lot of external assets yet.

I"m a belts-and-suspenders kinda guy so I don't want to rely on the "preserve" feature.  Early indications were that things broke and I'd be happy to revise and readjust my recommendations...

The nice thing about having the container data or other heavy data separate off is that it does not load with the rest of the record.

Wim,

At first I thought that I'd move the documents table to its own file and point my data file to it. However, it seems that you suggest that I keep documents in my data file, and just move the container field and ID to a separate file.

If I move the container field and ID to a separate file, how best to repoint the references? I want my UI file to only have an external ref to the data file. I was hoping that the data file would have an ext ref to the my_containers.fmp12 file.

However, if I use Insert File in the UI file, it seems to force me to specify my_containers.fmp12 as an external data source to the UI file. So, I don't have a chain, but rather a circle of references.

Barbara

You can't avoid a reference to the container file in the UI file unfortunately.

You could move the docs table as a whole but that may be less than ideal because the whole idea is to have as little as possible in the container file, in order to minimize the changes of having to deal with schema changes and ever having to import into that file.

Update complete! Thanks, Wim.

Any time!

Wim! Back upgrading this same client. Going from FMS12 to FMS15. 3 files (UI, data, documents). Ext. secure containers. Not a huge amount, btw, as they are just starting to really use the upload pdfs feature.

FMS15 is mac mini 4core. We're finally upgrading is RAM to 16GB and moving to an external SSD drive.

Recommended steps to maintain links to ext. stored containers during this upgrade would be appreciated.