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 2012). They run upgrade advisor and note that there are a whole lot of problems. They think "Hey that's way too much to deal with right now. I don't have time".
So they don't deal with them. They upgrade the server to 2012 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 2012, it tells them that they can no longer use it because their server is already at 2012. How can they now check what needs to be changed? They also cannot now reattach their databases to an earlier version server, as they've been upgraded to 2012 structure.
I believe that upgrade advisor should check db_compat levels, not server versions, before refusing to run. If you agree, you know what to do. Vote once, vote often:
Well it's been a while since I've posted up a new podcast. (I know, I know).
But I've just started a new series for SQL Server 2012. First out of the gate is Roger Doherty (Senior Program Manager in the SQL Server team) with an overview of all the key SQL Server 2012 pillars and enhancements.
You'll find it here:
Nice to see the increase in maximum database size on SQL Azure kicked up to 150GB.
In most enterprises I go into, there are a few databases that wouldn't fit but now the vast majority of databases would fit in SQL Azure.
Also included in the November release are federations and an updated management portal.
More info here: http://msdn.microsoft.com/en-us/library/windowsazure/ff602419.aspx
Over the years, I've seen several causes of this error in SQL Server Integration Services but today I came across another one.
You can get this error if you've used 3rd party components (particularly data sources) and the licensing for those components has expired.
Hope that helps someone sometime.
When you first make a connection to the new LocalDB edition of SQL Server Express, the system files, etc. that are required for a new version are spun up. (The system files such as the master database files, etc. end up in C:\Users\<username>\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBApp1) That can take a while on a slower machine, so this means that the default connection timeout of 30 seconds (in most client libraries) could be exceeded.
To avoid this hit on the first connection, you can create the required instance of LocalDB beforehand using the SqlLocalDB.exe utility, like this:
<path to binaries>\SqlLocalDB.exe create InstanceName
You can also specify the required version of SQL Server and ask to start the instance like this:
<path to binaries>\SqlLocalDB.exe create InstanceName 11.0 -s
Your application should then connect quickly, even on the first connection.
SqlLocalDB documentation is starting to appear now. Documentation on the utility is here: http://msdn.microsoft.com/en-us/library/hh212961(v=sql.110).aspx.