SQL 2014 Upgrade

[Seth_Yantiss]

Hello,

My DBA's are in the middle of upgrading from SQL 2008 to SQL 2012.  My DBA's do not want to do a restore of a backup from 2008.  They are wanting to do a fresh install.  

Does this sound logical to any of you Hyland DBA's?

[Nick_McElheny1]

Did they provide a reason for not wanting to do the backup/restore approach? I've done it in the past and it's worked well (in conjunction with the RecreateDBUsers script). I've not heard of using DBUtils for a fresh install as part of a SQL upgrade.

Thanks,

Nick McElheny | Trover Solutions, Inc.
Database Administrator

[Seth_Yantiss]

Nick,Thanks for the reply. They stated that restores to 2012 could only be done via placing the server into compatibility mode, which they do not want to do. This doesn't make a lot of sense to me, but that's what they are saying...

Cheers,
Seth

[Brad_Phillips · Accepted solution]

Dear Seth,

Thank you for using Community.  Hope I can solve your issue.

First off, I don't believe you need to head down the path of doing a fresh install of OnBase for a database upgrade.  Like Nick said, the backup/restore path has worked fine for our customers. 

I believe what your DBAs are referring to is the Database Compatibility Level.  Every database has a compatibility level, and in SQL Server 2012, you can go all the way back to compatibility level SQL Server 2005.  This makes it so if you have an application that has code specific to a version of SQL Server, you can still have it running on later versions of SQL Server by setting the compatibility level appropriately. 

OnBase doesn't have any code specific to versions of SQL Server, so changing the compatibility level hasn't been an issue for us.  However, we have some recommendations when changing compatibility levels:

1.  Make sure the database compatibility level is the same as the version of the database server it's running on.

2.  If you must change it, perform a backup beforehand, change it off hours, and do some testing before releasing it to the users.  There shouldn't be any issues, but it always pays to be cautious. 

If you have any questions or concerns, feel free to contact your first line of support. 

I hope this answers your question.

[Brad_Phillips]

Seth,

A couple additional comments to my original post.

1. A backup for this particular situation would be overkill. I originally mentioned that since I'm a big proponent of backups for any environmental change, but not necessary as changing the compatibility level doesn't fundamentally change the database schema or data itself.

2. All users should be out of the environment when making this change.

3. Even though OnBase itself doesn't have any code which is specific to a compatibility level, there may be your own custom code which could be impacted. So it's always beneficial to test before releasing this change to the users.

I hope this clears things up.