SQL Server Upgrading Compatibility Level from 2005 to 2012

Question

We have old database in SQLServer 2012 Enterprise in Compatibility mode: 90 - SQL Server 2005 . What are the consequence of changing database compatibility mode from 90 into 110-SQL Server 2012? Many legacy applications utilize the database. Nothing is breaking in QA automated unit and integration tests, however trying to review potential items which could be missing.

I understand backward compitability has issues, changing database from 110- to 90, eg any queries applying newer syntax or tempdb will fail.

However what kind of issues can occur going from 90 to 110? What items can break?

Answer 1

Best to read these articles by Microsoft:

• "Differences Between Compatibility Level 90 and Level 100" here
• "Differences Between Lower Compatibility Levels and Levels 110 and 120" here.

Most probable issues you could encounter are:

Going from COMPATIBILITY LEVEL 90 TO 100:

• The QUOTED IDENTIFIER session setting is honored when multistatement table-valued functions are created.
• The current language setting is used to evaluate datetime and smalldatetime literals in the partition function.
• The FOR BROWSE clause is not allowed in INSERT and SELECT INTO statements.

Going from COMPATIBILITY LEVEL 100 TO 110:

• PIVOT is not allowed in a recursive common table expression (CTE) query. An error is returned.
• Under compatibility level 110, the default style for CAST and CONVERT operations on time and datetime2 data types is always 121. If your query relies on the old behavior, use a compatibility level less than 110, or explicitly specify the 0 style in the affected query. Upgrading the database to compatibility level 110 will not change user data that has been stored to disk. You must manually correct this data as appropriate. For example, if you used SELECT INTO to create a table from a source that contained a computed column

Answer 2

However what kind of issues can occur going from 90 to 110? What items can break?

Well this is basically very subjective, while I cannot tell you what could break from the code side I could definitely point you towards article which list down all breaking changes. Please refer to Breaking Database Engine Changes in SQL Server 2012.

With my past experience changing database compatibility level does not makes database totally dysfunctional. The compatibility level only defines how certain features would work in certain compatibility level. To help you again MS has listed down such changes in ALTER DATABASE (Transact-SQL) Compatibility Level. The article is thorough and includes details of all versions of SQL server

Using above 2 links you need to jot down the what could possibly fail in your scenario and fix it beforehand. After this is done the process is easy you run the command

ALTER DATABASE database_name   
SET COMPATIBILITY_LEVEL = 110

Please make sure you run this during off production hours. Now you can ask users to test if something fails and it is really important for it to work run the command again and change compatibility level back to 90. So whole process also includes bit of hit and trial method.

Answer 3

You should review what changes were introduced between the versions you are referring to. If any of the changes affect your workload, you should test it thoroughly and make any necessary adjustments. Apart from syntax changes that might break your code, you should also test for performance as SQL Optimizer and other features might have been changed that would generate different query plans then they previously were.

Here is a link to some information on compatibility levels with reference relevant to MSDN pages: LINK