August 30, 2017 at 7:40 am
SQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.
We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
August 30, 2017 at 7:54 am
I don't think you've ever been able to connect to SSIS with a version of SSMS that was different.
IE, SSMS2012 to SSIS 2008R2 -> Fail
My suspicion would be, seeing as it's been that way for a long time, is that MS has no intention of trying to make SSMS able to connect to down-versions of SSIS. So in your case, yes, you'd either need to have both the 2016 SSMS and the 2017 SSMS, or just go with SSMS 2016.
August 30, 2017 at 8:35 am
Did you install the backward compatibility thingy? There is an option in the setup. You can most likely re-run the setup and add the feature.
😎
August 30, 2017 at 8:39 am
Harold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
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
August 30, 2017 at 8:40 am
I'm pretty sure the backward compatibility is for TSQL features, not SSIS. Like jasona.work said, SSMS has never been able to connect to a previous version of SSIS, and it's unlikely that Microsoft is going to change that.
Alan H
MCSE - Data Management and Analytics
Senior SQL Server DBA
Best way to ask a question: http://www.sqlservercentral.com/articles/Best+Practices/61537/
August 30, 2017 at 8:45 am
Phil Parkin - Wednesday, August 30, 2017 8:39 AMHarold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
How would you import your package? We have to connect to it, then upload our SSIS package.
August 30, 2017 at 8:56 am
Harold Buckner - Wednesday, August 30, 2017 8:45 AMPhil Parkin - Wednesday, August 30, 2017 8:39 AMHarold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
How would you import your package? We have to connect to it, then upload our SSIS package.
You can directly load packages from Visual Studio / SSDT, I believe.
August 30, 2017 at 8:59 am
jasona.work - Wednesday, August 30, 2017 8:56 AMHarold Buckner - Wednesday, August 30, 2017 8:45 AMPhil Parkin - Wednesday, August 30, 2017 8:39 AMHarold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
How would you import your package? We have to connect to it, then upload our SSIS package.
You can directly load packages from Visual Studio / SSDT, I believe.
Never seen that, I check for it.
August 30, 2017 at 9:01 am
Harold Buckner - Wednesday, August 30, 2017 8:45 AMPhil Parkin - Wednesday, August 30, 2017 8:39 AMHarold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
How would you import your package? We have to connect to it, then upload our SSIS package.
All of my packages are deployed to SSISDB. This can be done directly from SSDT or (for controlled environments) from source control using PoSh.
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
August 30, 2017 at 9:32 am
Phil Parkin - Wednesday, August 30, 2017 9:01 AMHarold Buckner - Wednesday, August 30, 2017 8:45 AMPhil Parkin - Wednesday, August 30, 2017 8:39 AMHarold Buckner - Wednesday, August 30, 2017 7:40 AMSQL Server Management Studio 17.2 cannot connect to SQL Server 2016 Integration Services. SQL Server Management Studio 16.5.3 connects fine to 2016 Integration Services. It appears it is the same issue we have been use to where to connect to Integration Services we have to use the same version SSMS as the Integration Services version.We are in the middle of planning our 2016 environment and what tools need installed on developers machines. Does anyone know if the plan is to not allow SSMS 17.x tools to connect to SQL 2016 Integration Services to upload packages? If it is not, I hate to move forward with 17.x tools on the developers machines. Then I would need both 16.5.3 and also 17.x on them and they are easily frustrated having to figure out which tool for what.
It would be nice to get clarification if this is a bug or will the SQL SSMS tools not "Really" be backward compatible?
I rarely need to connect to SSIS in SSMS, and I do a lot of SSIS development. Do your developers really need it?
How would you import your package? We have to connect to it, then upload our SSIS package.
All of my packages are deployed to SSISDB. This can be done directly from SSDT or (for controlled environments) from source control using PoSh.
We don't deploy to the SSISDB catalog and that looks to be the only way from SSDT. You can deploy using the manifest and the deploy wizard but IS would ned to be installed on their machines. I'll keep looking into it.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply