April 23, 2013 at 11:37 pm
Should 2005 SMO be able to access SQL 2012 please?
We are currently performing a large migration to SQL Server 2012. It's been going well, but we have hit a problem testing an app. An app server is throwing an exception "This SQL Server version (11.0) is not supported". On further investigation an internal library (used potentially in a number of places) is found to be using Microsoft.SqlServer.ConnectionInfo 9.0.242.0.
Testing seems to show that referencing a later library works.
Is this expected behaviour that 2005 SMO library can't access SQL 2012?
What are our options - the dev teams are nervous of installing a later version and changing this internal library to reference it (although tests have shown this works). Any simple ways around it?
regards
April 26, 2013 at 3:43 am
Yes, it is expected that SQL 2005 SMO will have problems connecting to SQL 2012. You need to upgrade to a newer version.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 1, 2013 at 7:08 am
Hello,
You may have at least 2 problems when you are writing a SMO application :
1- between 2 SMO versions , you can discover that classes may change of namespaces ( the 1st well-known example is the Backup class which has changed its namespace )
2- another problem which is annoying when you are using a SMO application built on a former version of SMO ( for example 2005 ) against a latter version of SQL Server ( 2008 R2 or 2012 ) is appearing with the use of enumerations of which the number of values has changed ( mainly increasing for the latter version , but it seems it was the contrary for at least 1 enumeration in the Smo.Wmi namespace )
In theory , an application written with SMO 2012 is working in 99% of cases against any version of SQL Server ( at least >= 2000 ). But the payload may be heavy as you have for each SMO namespace to set the value of Copy local to true in your Visual Studio with the consequence that the executable will be huger than for the classical way : the referenced assembly is copied in the output directory. Advantage : you are not depending of the assemblies existing on the computer on which the application is running.
In practice , you have to maintain your application only for the last version of SQL Server and when a new SQL Server version is released , you have to recompile after having verified whether some classes have not migrated from a namespace to another one.
You have to be prepared that a property existing in the latest version doesn't exist in a former one. The best way is to test whether the property is existing in the current SQL Server and to decide what to do in case of absence of the property.
It is what I am doing in my SMO applications and since 2006 ( SQL Server 2005 SP2 ) , I think I met only 2 problems that I bypassed easily.
Have a nice day
September 1, 2013 at 11:13 am
Many thanks
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply