August 16, 2018 at 1:51 pm
I've been asked to reverse engineer and update many SSIS packages created on SQL Server 2014. The target production environment is using SQL Server 2014. However, my work laptop has SQL Server 2012 and Visual Studio 2017 installed on it. When I installed the SQL Server Data Tools, it became part of Visual Studio 2017.
Will I be asking for trouble by viewing and updating old SSIS packages using these different tools, or will all this likely not matter?
I'm just starting out, so if it makes more sense to remove all this from my laptop and install SQL Server 2014 and SSDT for it, now is the best time to get that all set up.
August 16, 2018 at 2:09 pm
bwelch42 - Thursday, August 16, 2018 1:51 PMI've been asked to reverse engineer and update many SSIS packages created on SQL Server 2014. The target production environment is using SQL Server 2014. However, my work laptop has SQL Server 2012 and Visual Studio 2017 installed on it. When I installed the SQL Server Data Tools, it became part of Visual Studio 2017.Will I be asking for trouble by viewing and updating old SSIS packages using these different tools, or will all this likely not matter?
I'm just starting out, so if it makes more sense to remove all this from my laptop and install SQL Server 2014 and SSDT for it, now is the best time to get that all set up.
SSDT in Visual Studio 2017 can edit packages from SQL Server 2012, 2014, 2016 and 2017. Just right-click the project in Solution Explorer (not the solution) and go to the General tab under Configuration Properties. There you will see the Target Server Version option.
August 16, 2018 at 2:26 pm
Thanks. I don't have any projects or solutions, only the SSIS dtsx files. From SS2017, I created a new project, adjusted the target server to be SS2014, and then loaded the dtsx file for that project. All appears to be working well.
Should I see about updating my local SQL Server version from SS2012 to SS2014 to match the target version?
August 17, 2018 at 5:38 am
bwelch42 - Thursday, August 16, 2018 2:26 PMShould I see about updating my local SQL Server version from SS2012 to SS2014 to match the target version?
It's always a good idea to have your dev environment as close as possible to your target environment, as it reduces the likelihood of surprises (particularly given the introduction of the new cardinality estimator in 2014) after deployment.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply