Right click on the project and select properties. So starting with the project I created for SQL 2016: In fact I’ll probably do one more in a week or two because of this also.) (Yes I wrote 3 posts for no purpose other than to lead up to this one. So to start with I installed SSDT 17, created a project, and practiced deploying to the SSIS catalog on a 2016 instance.
Prior to this, you would have to have scripted the package out in BIML and re-created it in the correct version. I have a table I try to maintain the different version of packages etc to help out with the confusion.įortunately though, one of the big changes (in my mind) of SSDT is the ability to change SSIS versions. If you work in a large company with multiple versions of SQL running, and multiple teams creating SSIS packages for those different versions it can be a real mess. You’re also going to have problems running it on that original SQL 2012 instance. And now you can’t open that same package in SSDT 2012. You run the package and SSDT automatically saves it. SSDT automatically upgrades your to package version 8 (SQL 2014 & 2016). You later open that same package with SSDT 16 without thinking about it. Let’s say you create a package in SSDT 2012. Of all of the annoying parts of SSIS, the major version sensitivity has to be the most annoying.
0 kommentar(er)
