BugBash - Upgrade advisor should check database db_compat level, not server version (still an issue) - by Greg Low - Australia

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 715400 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 12/23/2011 4:36:12 PM
Access Restriction Public


We have a very common customer scenario where the customer decides to upgrade to a new version (in this case let's say SQL Server 2016). They run upgrade advisor and note that there are a whole lot of problems. So they don't deal with them. They upgrade to 2016 but leave their db_compat level at a lower level with the intention of dealing with the problems later.

But when they go to run the upgrade advisor later, to find the issues that they need to resolve before changing db_compat level to 2016, it tells them that they can no longer use it because their server is already at 2016. Yet they also cannot now reattach their databases to an earlier version server either.

How do they now find the issues that need to be resolved?
Sign in to post a comment.
Posted by Greg Low - Australia on 6/29/2012 at 5:58 PM
Hi Folks,

I wish that was a workaround but it's not. That's only a workaround for someone who:

* ran the report on the earlier version at the time
* had the foresight to keep the report
* made no code changes in the intervening years

Practically, that would be almost no-one. Many people upgrade and keep the db_compat level the same, either because they just restored/attached the databases, didn't even know about it, or because they were worried about potential issues and thought it would help.

It doesn't make sense to have no way for people to check for issues once they've upgraded the server but no increased the db_compat level of the databases.


Posted by Joe [MSFT] on 6/29/2012 at 1:02 PM
Hi Greg,
Thank you for writing in. There is a work around for this issue. The Denali UA assessment report is saved in %USERPROFILE%\Documents\SQL Server Upgrade Advisor\110\Reports\<machinename>. You can access them directly from the folder or you can access them from the UA report interface. The report can be used as a manual tracking mechanism for issues to be addressed. We realize this is not ideal but it is the only workaround for now.

We understand your frustration around the changing of hands. We have discussed this request amongst our teams and, at this time, we are not able to commit to this enhancement. However it is visible to all teams to consider via our backlog when planning for the next version.
Posted by Greg Low - Australia on 1/4/2012 at 10:09 PM
Hi Mo Lin,

Unfortunately, just before a new version of the product ships, many of these sorts of things seem to get closed as "Won't Fix" but we've been assured that it doesn't mean they'll get lost for the future. But they still often seem to get lost. When you then combine that with a regular turnover of staff within the product groups, there is a real lack of organizational knowledge about such things. The new people coming in often have no idea about previous discussions on these sorts of topics. I wish there was a way to change that.


Posted by Mo [MSFT] on 1/4/2012 at 5:36 PM
Hi Greg – The #282567 was closed as won’t fix by ex-owner, that’s why it didn’t show up on my radar when I planned for Denali Upgrade Advisor. For this feedback - 715400, I will keep it as Active so that we can assess it appropriately when next development cycle for UA is opened.

Mo Lin
Program manager
Microsoft SQL Team
Posted by Greg Low - Australia on 1/4/2012 at 2:08 AM
Hi Mo Lin,

Here's an example that was previously submitted: https://connect.microsoft.com/SQLServer/feedback/details/282567/upgrade-advisor-needs-to-run-against-sql-2k5-in-compat-80-mode


Posted by Mo [MSFT] on 1/3/2012 at 11:02 PM
Hi Greg – unfortunately the development cycle for Denali Upgrade Advisor is closed already. And it is weird that I did not see your feedback before. Do you keep the feedback ID that you previously submitted for this issue?

Posted by Greg Low - Australia on 1/3/2012 at 7:29 PM
Hi Mo Lin,

That's great to hear but sadly, that's the same feedback I received when I reported it for SQL Server 2008, and again for SQL Server 2008 R2.


Posted by Mo [MSFT] on 1/3/2012 at 6:56 PM

Thanks for your feedback. Today Upgrade Advisor is designed to check at server version first so it blocks further checking at db_compat level. However the requirement described in your feedback is a valid scenario and valuable to users, we will take it into account in the next version of Upgrade Advisor.

Mo Lin
Program Manager
Microsoft SQL Team