Uploading new .fmp12 revision to server wipes out all container fields

[CaseyBailey]

This problem is absolutely driving us nuts, and has been for a week straight. Full disclosure, I just started this job and have never worked with FM before, so I have no doubt we're just missing something. Here's what's happening:

We have an application that stores all of its images in an external container field set to [hosted location]/[database location]/Files/Container. The images were originally stored inside of SuperContainer, so we wrote a quick script to import them into the new version of our application. This worked fine.

The issue we're now having is that we have a variety of servers as well as clients running our app on their own local servers, and deploying a new version of our .fmp file erases the link to every single image. This is a problem we absolutely have to fix, since we really can't rely on re-importing 20+ gigs of images into every new release for 20+ clients. Help please!

[Ocean West]

I'd stick with SuperContainer since it's already purchased and deployed. - for these mission critical things.

it's nature is different from FMP - your container data can be stored separately from the FileMaker server.

if your doing a lot of uploading and downloading that can be very time consuming, using native remote containers.

here is the white paper for using container fields https://fmdev.filemaker.com/docs/DOC-2585 ( log in required )

[CaseyBailey]

Thanks for the quick help! Sadly, I'm just the lowly programmer and my boss refuses to continue using SuperContainer for various reasons. I'm checking out the white paper now though!