January 20, 2015 at 9:29 am
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?
Thanks guys.
January 20, 2015 at 10:33 am
JoshDBGuy (1/20/2015)
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?Thanks guys.
I haven't done it, but I'm assuming that your 2014 install is a different instance. So I would have thought that it should just be a case of redeploying your SSIS projects and copying your folders and environments over to the SSISDB on the 2014 instance – after upgrading the packages, of course.
But I would test that somewhere other than production first.
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.
January 20, 2015 at 10:42 am
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?Thanks guys.
I haven't done it, but I'm assuming that your 2014 install is a different instance. So I would have thought that it should just be a case of redeploying your SSIS projects and copying your folders and environments over to the SSISDB on the 2014 instance – after upgrading the packages, of course.
But I would test that somewhere other than production first.
That's the interesting thing. The instance is 12.0 (2014) but the SSIS catalog is 11.0 (2012).
January 20, 2015 at 10:45 am
Sorry but I don't have a clue – I did not know that was even possible!
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.
January 20, 2015 at 10:51 am
JoshDBGuy (1/20/2015)
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?Thanks guys.
I haven't done it, but I'm assuming that your 2014 install is a different instance. So I would have thought that it should just be a case of redeploying your SSIS projects and copying your folders and environments over to the SSISDB on the 2014 instance – after upgrading the packages, of course.
But I would test that somewhere other than production first.
That's the interesting thing. The instance is 12.0 (2014) but the SSIS catalog is 11.0 (2012).
Did you get that info by right-clicking on the SSISDB catalog under 'Integration Services Catalogs', or via some other method? What does the 'Schema Build' property show?
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.
January 20, 2015 at 11:01 am
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?Thanks guys.
I haven't done it, but I'm assuming that your 2014 install is a different instance. So I would have thought that it should just be a case of redeploying your SSIS projects and copying your folders and environments over to the SSISDB on the 2014 instance – after upgrading the packages, of course.
But I would test that somewhere other than production first.
That's the interesting thing. The instance is 12.0 (2014) but the SSIS catalog is 11.0 (2012).
Did you get that info by right-clicking on the SSISDB catalog under 'Integration Services Catalogs', or via some other method? What does the 'Schema Build' property show?
Yes, right-click. Schema Build shows 11.0.
January 20, 2015 at 11:14 am
JoshDBGuy (1/20/2015)
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
I inherited an environment with a SQL Server 2014 environment. It looks like they installed 2014 SSIS concurrently with 2012, leaving both services on the box. They then deactivated SSIS 2014, so currently, only 2012 is running. This is causing problems for me now because I'm trying to convert older DTSX packages to 2014 and put it in the SSIS catalog. This can't be done with SSDT 2014 because it's a different version than what's running. I would like to spin up 2014 but I am worried that I might see some issues. Can I expect problems? Do I need to convert the current IIS catalog?Thanks guys.
I haven't done it, but I'm assuming that your 2014 install is a different instance. So I would have thought that it should just be a case of redeploying your SSIS projects and copying your folders and environments over to the SSISDB on the 2014 instance – after upgrading the packages, of course.
But I would test that somewhere other than production first.
That's the interesting thing. The instance is 12.0 (2014) but the SSIS catalog is 11.0 (2012).
What a mess. I would install a new instance of SQL 2014 and install a SSIS 2014 catalog there.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
January 20, 2015 at 11:18 am
That's going to be a nightmare, I'd prefer to not do that.
January 20, 2015 at 11:20 am
JoshDBGuy (1/20/2015)
That's going to be a nightmare, I'd prefer to not do that.
I'm not sure why a SQL Server instance would be a nightmare.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
January 20, 2015 at 11:48 am
Koen Verbeeck (1/20/2015)
JoshDBGuy (1/20/2015)
That's going to be a nightmare, I'd prefer to not do that.I'm not sure why a SQL Server instance would be a nightmare.
It's not a nightmare, that was an exaggeration, but with all of the other stuff I'm working on, I'd rather not do that. My hope was I could remove ssis 12.0 as it's not being used and then upgrading 11 to 12.
I was thinking I could run the uninstall services process, uninstall 2014 ssis. Then run the upgrade of the 2012 service to 2014.
January 20, 2015 at 12:00 pm
JoshDBGuy (1/20/2015)
Koen Verbeeck (1/20/2015)
JoshDBGuy (1/20/2015)
That's going to be a nightmare, I'd prefer to not do that.I'm not sure why a SQL Server instance would be a nightmare.
It's not a nightmare, that was an exaggeration, but with all of the other stuff I'm working on, I'd rather not do that. My hope was I could remove ssis 12.0 as it's not being used and then upgrading 11 to 12.
I was thinking I could run the uninstall services process, uninstall 2014 ssis. Then run the upgrade of the 2012 service to 2014.
Given the unusual nature of the task and 2014's newness, I don't think you'll find many people who have done that, so you might have to experiment in the knowledge that it could all go wrong. So have a recovery plan ready.
By the way, the Integration Services service actually does very little: you can turn it off and you'll still be able to work just fine (see here[/url]).
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.
January 20, 2015 at 12:02 pm
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
Koen Verbeeck (1/20/2015)
JoshDBGuy (1/20/2015)
That's going to be a nightmare, I'd prefer to not do that.I'm not sure why a SQL Server instance would be a nightmare.
It's not a nightmare, that was an exaggeration, but with all of the other stuff I'm working on, I'd rather not do that. My hope was I could remove ssis 12.0 as it's not being used and then upgrading 11 to 12.
I was thinking I could run the uninstall services process, uninstall 2014 ssis. Then run the upgrade of the 2012 service to 2014.
Given the unusual nature of the task and 2014's newness, I don't think you'll find many people who have done that, so you might have to experiment in the knowledge that it could all go wrong. So have a recovery plan ready.
By the way, the Integration Services service actually does very little: you can turn it off and you'll still be able to work just fine (see here[/url]).
That's some great information. I thought packages would not run, thank you.
January 20, 2015 at 12:51 pm
JoshDBGuy (1/20/2015)
Phil Parkin (1/20/2015)
JoshDBGuy (1/20/2015)
Koen Verbeeck (1/20/2015)
JoshDBGuy (1/20/2015)
That's going to be a nightmare, I'd prefer to not do that.I'm not sure why a SQL Server instance would be a nightmare.
It's not a nightmare, that was an exaggeration, but with all of the other stuff I'm working on, I'd rather not do that. My hope was I could remove ssis 12.0 as it's not being used and then upgrading 11 to 12.
I was thinking I could run the uninstall services process, uninstall 2014 ssis. Then run the upgrade of the 2012 service to 2014.
Given the unusual nature of the task and 2014's newness, I don't think you'll find many people who have done that, so you might have to experiment in the knowledge that it could all go wrong. So have a recovery plan ready.
By the way, the Integration Services service actually does very little: you can turn it off and you'll still be able to work just fine (see here[/url]).
That's some great information. I thought packages would not run, thank you.
No no, all the service does is keeping track of packages running in the package deployment model and to display the packages in a tree structure when you log into the service. When using the project deployment model, it's of very little use. You can safely disable it.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply