Seemingly basic multiple-client version upgrade method

[CaseyBailey]

This is a fairly easy problem that most languages/systems handle gracefully, but I'm relatively new to FM in general and can't figure out a more streamlined process than the extremely-time-intensive method we're using now.

 

The situation:  We're constantly developing a rather large FM solution in-house.  We have 30+ clients who purchase our solution.  We then host a separate instance of our solution for each client on a server we control running FMS12.  Everything works fine BUT -- Let's say we release an updated version every 2 weeks that includes scripting/layout bug fixes and new functionality.  Right now, our way of upgrading all clients to this new version is to manually Close each client's instance by hand, download it from FMS to the desktop, manually replace the old db file with our new one while leaving the external container folders intact, rename the old db file to "Source", then manually run a large script that imports all of the client's database data from "Source" into our new version.  We then have to re-upload this 'upgraded' version to FMS and restart it.

 

This *DOES* work, in that it keeps client images/data intact while replacing the FM scripting/layouts with our new versions, but I'm sure you can tell just how outrageously long this takes to do by hand.  As we gain more clients, the time required is becoming entirely unmanageable and I feel like there HAS to be a better way that I simply don't know about.

 

Help please

[bcooney]

One approach is called the Separation Model. It attempts to separate interface from data. Otherwise, yes, your method is what is done.

[David Jondreau]

Just to be clear, the hosted files are for your development purposes? And the client's versions are also hosted on the same server?

 

You can develop on the same files they're using...though there are other considerations with that approach like making sure the clients use isn't affected by development (like working at night, working on a separate file and copying and pasting into the live file to reduce the time you're editing, developing on the server machine to reduce the chance of a network failure while editing, etc).

 

If that's not feasible, as Barbara says, the separation model will make things easier. All the data is in one file, all the layouts, all the scripts, and most of the relationships are in another file. That will eliminate many imports (those when you're not changing tables and fields).

 

You can also script the import so it runs from one hosted version to the other. No need to download the file. You'd probably want to do that from a Pro client running on the server. It you want to get fancy, you could run it as a server-side script, but since server won't import from one FM file to another, you'd need to export data to another format first, then import.

[Rick Whitelaw]

I fail to understand why you would run a separate instance of your solution for each client as opposed to implementing security measures like record level access etc. I say this not because I'm certain I'm correct but because I need to learn about these matters.

[David Jondreau]

I can think of a couple reasons...RLA is pretty annoying to implement. It takes a lot of attention to detail to get right, and to have the interface look reasonable. Performance could be an issue with 30 clients and how many users per client? Also, there may be small client customizations on the schema of specific files.

[bcooney]

I agree with David. My first reaction was, yikes, so many versions of a system. However, they might deviate in functionality, and to have multi-clients hit a system, you would need pristine RLA and interface to avoid data exposure.

 

But, let's all take a moment to wish it was easier to upgrade a production system.

[dansmith65]

It sounds like you already have a script to migrate the data, but I thought RefreshFM http://www.goya.com.au/refreshfm should be mentioned since it helps with this task. I've just started using it myself, and like it. The basic process is still the same as what you are doing now, but it does automate a few of the steps.