Upgrading to 6.0

[sbaum]

Hi, our server and clients are currently on version 5.4.  I'm testing out the 6.0 client and it is working fine with the 5.4 server.  If I want to upgrade the server to 6.0 is that an easy process like upgrading between versions of 5.4 (like from 5.4.16.867 to 5.4.16.918), or is there additional configuration I will have to do since 6.0 is a major version?  I'm not looking to switch the database to Jet yet, I'd like to keep MS SQL for now.

Thanks!

Steve

[wnicholls]

I upgraded a server from 5.4 to 6.0 just fine without any issues.  I'm usually pretty gung-ho about Plastic upgrades, (relying on having a good backup system in case something _does_ go wrong) but for me every time is faultless.

I can't really tell you what 6.0 with SQL is like, because I did switch to Jet pretty soon after the upgrade.

This is an aside, but as far as faultless goes, I can't say the same for the migration from SQL Server to Jet though. The main issue here is that it has to be done per server and all repositories have to be done at once.  Codice's own recommendations probably are along the lines of "set up a second server, and migrate all the repos over, then when you're happy, turn the first server off" and although I wouldn't go that far, I would definitely recommend (a) Get all users to check in their work  (b) back up (c) backup again! (d) get the users to back up their workspaces; and (e) test very carefully after the migration.

Reverting back to SQL I *think* is just a case of changing the db.conf  file back.  (I'm sure I did that when, back in 5.x days, I tried to replace MS Sql with MySQL. That *was* a complete disaster for me, but for posterity/observers, I'll just say Plastic apparently works just fine with MySQL for anyone else).

I had one repository where a changeset seemed to have vanished after the conversion to Jet, leaving a workspace in very strange state.  I don't know the reason for it, everything else is ok, so doubt that will be a very common case, but there isn't that much experience of migrations to Jet out there yet. I recovered by taking a copy of the workspace, deleting and recreating it and updated to get the latest version the _server_ thought there was, copying the original workspace files over the top, and checking in again.  You can imagine how scary that would have been if the I didn't have all the changes somewhere.

[manu]

Hi @sbaum!

It's as easy as upgrading from  5.4.16.867 to 5.4.16.918. No database upgrade is needed for this jump so the databases schema are not going to be changed, although it's always good to have an updated backup. This 5 to 6 upgrade is really really easy.

BTW, there's a way to migrate to jet in an incremental way, you can export you data little by little and once you are ready you import the last piece, switch the db.conf to a jet.conf and it's done. Contact support if you are interested.

[sbaum]

Thanks Manu!  We have over 160 repositories.  Is it hard to migrate that many over to Jet from MS SQL?

[sbaum]

13 hours ago, wnicholls said:

I upgraded a server from 5.4 to 6.0 just fine without any issues.  I'm usually pretty gung-ho about Plastic upgrades, (relying on having a good backup system in case something _does_ go wrong) but for me every time is faultless.

I can't really tell you what 6.0 with SQL is like, because I did switch to Jet pretty soon after the upgrade.

This is an aside, but as far as faultless goes, I can't say the same for the migration from SQL Server to Jet though. The main issue here is that it has to be done per server and all repositories have to be done at once.  Codice's own recommendations probably are along the lines of "set up a second server, and migrate all the repos over, then when you're happy, turn the first server off" and although I wouldn't go that far, I would definitely recommend (a) Get all users to check in their work  (b) back up (c) backup again! (d) get the users to back up their workspaces; and (e) test very carefully after the migration.

Reverting back to SQL I *think* is just a case of changing the db.conf  file back.  (I'm sure I did that when, back in 5.x days, I tried to replace MS Sql with MySQL. That *was* a complete disaster for me, but for posterity/observers, I'll just say Plastic apparently works just fine with MySQL for anyone else).

I had one repository where a changeset seemed to have vanished after the conversion to Jet, leaving a workspace in very strange state.  I don't know the reason for it, everything else is ok, so doubt that will be a very common case, but there isn't that much experience of migrations to Jet out there yet. I recovered by taking a copy of the workspace, deleting and recreating it and updated to get the latest version the _server_ thought there was, copying the original workspace files over the top, and checking in again.  You can imagine how scary that would have been if the I didn't have all the changes somewhere.

That's for the info!  I think we will probably stick with SQL Server for now as we don't really have any performance issues.  We  do sometimes have issues when the service starts up because we have 160 repositories and if too many are setup to Auto Close then Plastic times out trying to start all of them.  We've basically gotten into the habit of setting Auto Close to false when we create a new repo so that it is always on.  At this point we haven't run into any issues but I'm not sure if having that many databases open will eventually catch up to us.

[manu]

On 9/15/2017 at 3:08 PM, sbaum said:

Thanks Manu!  We have over 160 repositories.  Is it hard to migrate that many over to Jet from MS SQL?

Not really, it's the same process as exporting a single one. Nothing extra or custom has to be made.

You can use the admin tool or if you want us to assist we can do it in an incremental way so you can keep using SQLServer until the switching day.