Updating an already deployed database on a server with new version of DB

[rkass068]

Hello,

 

So this is a weird question I find and I am sorry for any confusion. I am developing a database for a bunch of doctors and I already deployed it on FM server. It is working great but the docs have a weird request. Usually I would update the database and make tweaks directly to the DB via the administrative account by remotely connecting to FM server. It was working great but for some reason the docs want me to create a "new" version of the DB. Rename it and then transfer all the data from the old DB to the new. 

 

To be honest I have no idea how to do that because I can just update it "on the fly" by connecting to FM server on our dedicated server. Right now what I did was i copied the old DB that jus being used and I am writing down every single change I make so that once the new version is done and tested by the docs I will just make the changes on the old DB. This is extremely tedious and to be honest pointless but I have to listen to the people that pay me. 

 

Any suggestions on what to do?

 

Thanks

 

[David Jondreau]

Tell the people that pay you that it shall cost five times more to do it the new way versus the old.

[sijmons]

Your client is right to demand an option to mirgate data to a new version, these solutions tend to become mission-critical over time and it is not the safest way to develop on a live production system.

 

There are several options you can follow but you can script all data migration between versions (.e.g. pass over every base table layout and import from a folder where your previous version resides)

Be very careful about primary keys and serial counter resets in this process, test test test.

 

It will be worth it.

[rkass068]

Tell the people that pay you that it shall cost five times more to do it the new way versus the old.

 

hahahahah! I like the sound of that! 

Your client is right to demand an option to mirgate data to a new version, these solutions tend to become mission-critical over time and it is not the safest way to develop on a live production system.

 

There are several options you can follow but you can script all data migration between versions (.e.g. pass over every base table layout and import from a folder where your previous version resides)

Be very careful about primary keys and serial counter resets in this process, test test test.

 

It will be worth it.

 

Oh okay, thanks but how exactly can I do that. What are the script functions? Is there some sort of guideline online that I can follow? Thanks for the help. By the way I notice you're in Netherlands and just want to say good luck to their football team! They look amazing so far

[sijmons]

There are specific script steps for imports.

 

No offence, but if you know very little about these steps or are new to the concept of data migration between versions, this may be an area you would want to stay away from. This process has to run without a hitch and should contain all possible sorts of error traps and error reports. Data loss is the worst scenario for an end user.

Consult with an experienced FileMaker developer, they can build this in as most have dealt with this issue several times before.

 

From then on, you can do your own maintenance again for the doctors when they want small tweaks.

From the FileMaker website you can find developers, possibly at a location near you or you post for help on this forum.

 

Success !

 

more dutch football tomorrow !

[Wim Decorte]

While you can build it yourself, you can also get this excellent product and be done with it.  In the end it is going to be much cheaper (and more robust):

 

https://www.goya.com.au/refreshfm

[rkass068]

While you can build it yourself, you can also get this excellent product and be done with it.  In the end it is going to be much cheaper (and more robust):

 

https://www.goya.com.au/refreshfm

 

Oh thanks! looks cool. I will tell the doctors about it. If they don't want to purchase it then I will just tell them Ill have to do it the way I was before. Thanks

There are specific script steps for imports.

 

No offence, but if you know very little about these steps or are new to the concept of data migration between versions, this may be an area you would want to stay away from. This process has to run without a hitch and should contain all possible sorts of error traps and error reports. Data loss is the worst scenario for an end user.

Consult with an experienced FileMaker developer, they can build this in as most have dealt with this issue several times before.

 

From then on, you can do your own maintenance again for the doctors when they want small tweaks.

From the FileMaker website you can find developers, possibly at a location near you or you post for help on this forum.

 

Success !

 

more dutch football tomorrow !

Thanks!