Migrating from V6 to V7 on another server

tford

I'm finally in the process of transferring over some BSVs from a V6 server to a V7 server. This process will take a few weeks as I refine and tweak the BSVs.

In the V6 server, all the tables are currently in one MySql database. As a result, they all share one bas_idgen table which as I understand it holds the ID last used by any of the BSVs in that database. It seems that even if I copy over the value currently in the bas_idgen table from the V6 server to the V7 server at the same time that I can transferring over the first BSV, I will then run the risk of duplicate IDs at a later date when additional BSVs are moved from V6 server to V7 server.

Anyone run into this before?

tford

I created a BSV on the V7 database to hold a BSV called Updates and checked the box for "allocate separate database with the name ___"

I thought this would then create an new ID file just for that BSV, but my tests indicate that did not. The Updates BSV still uses the bas_idgen table in the basdb.

So ... now I'm really at a loss. Hoping that support or someone can shed some light on a path to solve this.

customaware

Why don't you just copy the entire V6 database over to the New server Tom and them Update it with V7?

Am I missing something?

ACDC

All the IDgen table does is allocate a unique ID no for the next new object to be created

The solution here in your case (because you are migrating various BSV's using a phased approach) would be to edit the new V.70 database IDGEN table to a number that is 1 million ahead of the v6.0 IDGEN table ( or a suitable no based on the activity in your V6 database ). This way when your last BSV is moved over the last number in the IDGEN table will not have reached the start IDGEN number in your V7.00 thereby preventing a duplicate

I spent some time evaluating the concept of 10 remote standalone applications running on Laptops and eventually synchronising to the online server app when connecting back to the network. The solution as far as duplicate ID's go from Vladimir was to make each IDGEN table on the remote laptop start at 10 million apart from each other (Obviously a number that is potentially unattainable between devices and server). So this practice was validated by support as being acceptable

tford

Why don't you just copy the entire V6 database over to the New server Tom and them Update it with V7?

Am I missing something?

Mark -- unfortunately the very detailed VP layouts I designed for some of my V6 BSVs don't display in the same way in V7 making the screens not functional for users. So I am forced to do a phased transition as I work through transitioning the BSVs.

The solution here in your case (because you are migrating various BSV's using a phased approach) would be to edit the new V.70 database IDGEN table to a number that is 1 million ahead of the v6.0 IDGEN table ( or a suitable no based on the activity in your V6 database ). This way when your last BSV is moved over the last number in the IDGEN table will not have reached the start IDGEN number in your V7.00 thereby preventing a duplicate

Thanks ACDC .. I'll give that a shot.

customaware

I don't see how that would make a difference Tom.

I you need to do some redesign on the VPs then you will need to do the same amount of work regardless.

Only downside I see is if you want the data to be off line for as short a time as possible and hence doing them one by one means you can get them functional again one by one

tford

Only downside I see is if you want the data to be off line for as short a time as possible and hence doing them one by one means you can get them functional again one by one

That's really the key, Mark. I can't afford downtime in a few of the BSVs.

tpis001

Hi Tom.... We have a slightly different setup to you, but as far as our migration strategy goes, we set up a parallel environment running V7 - so this is some non production server running V7.

We then set about fixing all the migration issues with VP's and other aesthetic stuff.

Once this is all complete, we migrate all bsv's in one go to a new production environment.

No need to tinker with bas id gen stuff.

Our approach means we enter a period of 'branching', where we have a production bsv's where we only apply critical fixes (which we also replicate in the migration bsv).

When we are satisfied with the results, we switch it all over seamlessly on some weekend.

ACDC

No need to tinker with bas id gen stuff.

It's not about tinkering, It's the normal thing to do when working with multiple databases, failover and replication. This is the only way to maintain unique ID's.

The bas_idgen object has only one attribute and all it is used for is to create the next ID no for the next new Object being created, so it's a simple thing to do

As long as you NEVER EVER sync or copy over the bas_idgen table,.. that would really cause mayhem