I have a bunch of SSIS packages created in SQL Server 2012. As new SQL Server versions come out, we have to provide a these packages in a format for SQL Server 2014, 2016 (every time for a new SQL Server version).
To do this, we manually upgrade packages, and store them in our repository for each SQL Server version. Obviously, this isn't great as the only difference is the SQL Server version they are compatible with.
Currently, there is an Integration Services project behind these in Visual Studio 2017, and via the IDE, you can upgrade all the packages via the flick of a switch.
Ideally, I'd like my Jenkins CI to do this conversion for me to each SQL Server version and make the packages available in each SQL Server version. Can this be done? I don't want to store every version package in my repo for distribution really...
TIA.
Related
Running Visual Studio 2017 with latest patches and SQL Server Data Tools installed. Created a new Integration Services project, target server version is SQL Server 2012. Added an existing SSIS package from a SQL Server 2012, made a small edit a task, and saved. When I try to deploy via package model, I get this error:
Storing or modifying packages in SQL Server requires the SSIS runtime and database to be the same version. Storing packages in earlier versions is not supported.
Since both the project and target server are both SQL Server 2012, I'm stumped on where the version discrepancy lies.
Previously I was able to download, edit, and re-save the package in VS 2010, so it seems to be something particular to Visual Studio 2017. Any ideas?
Edit: I also tried creating a new package in the project with nothing in it and it has the same error, so it's definitely something with VS 2017 and not code related.
In the property pages for an Integration Services project, on the General tab of Configuration Properties, select the TargetServerVersion property and choose SQL SQL Server 2012 and deploy it.
We're building an ETL Product in SSIS. A lot of our SSIS packages have script tasks written in C# script with assembly references to Microsoft.SqlServer.ScriptTask, Microsoft.SqlServer.ManagedDTS etc.
Some of our customers may be using an older version of SQL (2014) while some may upgrade to 2016.
What is the industry standard and best practice for such situations, where you can release newer product versions to both set of customers using old and new SQL Server versions?
Is there any way we can support both SQL Server 2014 and 2016 without having to maintain 2 code bases?
SQL Server 2014 and 2016 ssis package has the same PackageFormatVersion which is 8but the ManagedDTS.dll version differs between two versions.
For SQL Server 2014, version is 12.0.0.0
For SQL Server 2016, version is 13.0.0.0
For these reason, you cannot work with both version from the same application, because you must decide to choose between one of these DLL's.
Useful Links
Automate Version number Retrieval from .Dtsx files
What SQL version is my package?
Can some one tell me whether the SSIS packages developed in Visual Studio 2012 or 2013 works in 2008r2 server or not ???
If yes, did any other software needs to be installed in the 2008r2 server?
Deployment is not any concern here. I just want to run the packages in 2008r2 server via sql agent job
Please help.
No. Backwards compatibility is not an option. A package built in 2014 will not run on 2012. A 2012 package will not run on 2008 and a 2008 package will not run on 2005.
However, forward compatibility does exist so a 2005 package will run on 2008. 2008 will run on 2012, 2012 on 2014.
While I don't think this is your scenario, if you have the 2012/2014 SSIS packages deployed to a 2012/2014 server, you could run them from the 2008 server's SQL Agent task. It'd just be a matter of scripting the catalog.create_execution and catalog.start_execution BOL
Having that SQL Script, add a job step task of SQL and point the context over to your 2012/2014 server.
MSDN at https://msdn.microsoft.com/en-us/library/mt204009.aspx contains an overview of all the supported VS/SQLServer version combinations.
Basically, for SQLServer2008R2 SSIS development you will need BIDS (from the SQLServer installation).
The VS2012/VS2013 tools support only SQLServer2012/2014 SSIS development.
For VS2015, the Februari preview release of the SSDT-BI tools is intended to support multi-targetting SSIS package development (but only SQLServer2012-2016, no 2008R2), see also in the comments at http://blogs.msdn.com/b/ssdt/archive/2015/12/16/sql-server-data-tools-preview-update-for-december-2015.aspx
Note there is also something called BIML which is able to generate SSIS packages for different versions of SQLServer (incl 2008R2) from the same source code, so you could possibly use VS2012/VS2013 with BIDSHelper and then as a last step maybe generate packages for SQLServer2008R2.
We have SQL Server & SSIS 2014 in our local environment, and most of SQL Server 2014 in our production environment, except for the SSIS, which is still 2008.
So we're creating SSIS packages locally which can't be deployed to production, because the SSIS packages are not backwards-compatible.
Is it possible to create the packages locally to target SSIS 2008? If so, how?
Just to note, the SSIS packages are defined in Visual Studio 2008, so I don't understand why they're dependent on SQL Server 2014.
The format of the SSIS packages has change from SSDT 2012 to 2013/2014. I was facing that situation recently before a Go Live. A colleague had developed SSIS packages in SSDT 2013 with SQL Server 2012 as the target environment for the deployment. While the development and execution from within SSDT 2013 with SQL Server 2012 is no problem, the package is not deployable within the SSIS catalog of SQL Server 2012. SSIS Packages are NOT downward compatible. ...at least with respect to the deployment in the SQL Server SSIS catalogue.
Open the dtsx file in the editor and check the value for "PackageFormatVersion". Possible values are:
VS 2013/2013 = 8
VS 2010/2012 = 6
Unfortunately, you cannot open SSIS packages with PackageFormatVersion=8 in SSDT 2012 or lower in order to downgrade a package. You could of course figure out, how the format has changed. I started to do this but gave up after a while. The best possible solution was to redevelop the package in SSDT 2012. Argh!
So, when developing SSIS packages you must take care of the target SQL Server version and then decide to choose the right SSDT version.
I am installing TFS 2012 Express edition and I fail at the wizard that runs "Readiness check". It fails at the Data tier section.. with error
TF400533: In order for this wizard to upgrade to the latest version of SQL Server Express, you will first need to install Service Pack 2 or newer, and then re-run this wizard. It is recommended that you run Microsoft Updates which will install the current service pack automatically (You may need to enable Microsoft Updates from the Windows control panel).
Question:
What service pack 2 is this talking about. If its SQL 2008 R2, then I installed it and I get the same error. If its TFS 2012 or SQL 2012 , there is no SP2.
I did install SQL server 2012 express edition separately and and then re run the TFS 2012 express edition install, it still fails at the same point.
The problem is the version of SQL Express that is packaged with TFS is not capable of upgrading the older version of SQL express you have. It must be pulled forward for the upgrade to work. So, we detect you're behind the minimum version it's capable of upgrading and show that message.
This article discussed a few options. If windows update works for you (optional updates) that is the easiest path.
http://elhajj.wordpress.com/2012/09/26/on-dealing-with-tfs-error-tf400533/
If you run that SP2 installer directly (next, next, next), it can just install SP2 but not against the SQLExpress instance on your box (sigh). It's not obvious - if the above link doesn't get you going, let me know and I'll include more detailed steps.
How about SQL Server 2008 R2 SP2?
TFS 2012 Express will install SQL Server 2012 Express while TFS configuration is running, so my advice to you, you will need to uninstall any any instance of existing SQL server you have and re-run TFS configuration wizard, remember to backup any database you have before uninstall.
Uninstall an Existing Instance of SQL Server 2012
Uninstall an Existing Instance of SQL Server 2008 R2