Hello,
I installed SSIS on a server by itself, it is 2016 version 13.0 version I followed permission directions from the link below:
I tried to connect to SQL management studio version 16.3 version, to SSMS 18.4, and I get the following error message, I attached it. not sure why or what to do about the error "Class not Registered", any info will only help.
March 2, 2020 at 6:26 pm
You cannot connect SSMS to a different version of SSIS. If there is a requirement to use SSMS to access SSIS then you would need the 2016 SSMS to be able to do that.
What is it that requires accessing SSIS through SSMS? I have never found a reasonable answer to why this is necessary.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 2, 2020 at 7:09 pm
I have never found a reasonable answer to why this is necessary.
Me neither. I never need to do this, yet use SSIS a lot.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 2, 2020 at 10:06 pm
Hello Jeffrey and Phil,
thank you for taking the time to answer me post.
The reason I wanted to connect SSMS to SSIS was to make sure it was up and running before connecting my visual studio 2015 to deploy my SSIS packages, though I am going to deploy them and use the file way and not the SSISDB way.
wondering if there is a good way of testing SSIS is up, and if the only way to test is to deploy an SSIS package, then let me know, also is there any good practices I should configure SSIS to run optimally and security recommendations?
thanks in advance
As for best practices - I would say (and recommend) using the Integration Services Catalog. It provides the best options for securing your projects and packages, allows for managing the usernames/passwords for connections securely in the catalog and provides options using environment variables.
After installing Integration Services on the server - once I have validated the service itself is up and running I have not found any reason to 'test' to make sure it is running. It isn't actually required to be running (I believe) as the packages are actually executed using the dtexec command line.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 2, 2020 at 11:47 pm
+1. Another big benefit is the 'free' logging that comes with putting packages into SSISDB.
And that is correct about the IS service. It does not need to be running in order to execute packages. Here's a pertinent quote from some years ago, made by Koen Verbeeck:
The SSIS Service, quite simply, is responsible for managing the Integration Services interface in SQL Server Management Studio. It enables the ability to import/export packages, view running packages, and view stored packages. It really doesn't do anything more than that.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply