June 27, 2019 at 1:06 pm
Hi all,
I have about 30 packages to import into a 2016 server, that come from 2008. However each package takes about 20-25 steps to import, I'm thinking there has to be a more automated path...
..any ideas?
Thanks,
JB
June 27, 2019 at 1:09 pm
Do you have them in a project? SQL Server 2012 introduced the project deployment method using the SSIS Catalog; that just a few steps to deploy the whole lot (though does require an initial set up, which is a few steps as well).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
June 27, 2019 at 2:49 pm
Afraid I'm very new to Admin of SSIS, so not sure what's required to get them into project form.
June 27, 2019 at 2:58 pm
Afraid I'm very new to Admin of SSIS, so not sure what's required to get them into project form.
Are the packages already in a project in SSDT? If not, create an SSIS project in SSDT and then add the relevant packages to the project. You may well then want to change certain things, like Connection Managers, to project Connection Managers.
There's a lot lof changes between 2008 and 2012+ SSIS, that are not easily described in a forum post. I had a quick google, and found a couple of hits, such as here. The documentation covers a lot of there differences between the two here.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
June 27, 2019 at 3:06 pm
Thanks for your help, I had a quick read of the link, and unless my tired old eyes are deceiving me the method won't port parameters - and the packages have plenty of them 🙂
Thanks nonetheless!
June 27, 2019 at 3:19 pm
Thanks for your help, I had a quick read of the link, and unless my tired old eyes are deceiving me the method won't port parameters - and the packages have plenty of them 🙂 Thanks nonetheless!
Not sure what you mean there. Parameters are expanded in 2012+; you now have package and project parameters. You won't lose functionality you'll gain it. SSISDB is the way to go for so many reason; and if you don't want to have to deploy every package on it's own it let's you deploy the whole project in one go (which is specially what you asked here).
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
June 28, 2019 at 8:49 am
Probably better I fess up, I'm pretty new to SSDT I did't even know how to add packages to a project 😉
Ok I've clicked 'Add existing package', now window asks for the package path, but the problem is, each .dtsx is supplied to me in its own subfolder that also contains a .dtsConfig and .SSISDeploymentManifest file which are associated with it by the look of their names. So not sure how those files will be imported. Also no idea how to change each package's connections to a project-scope, or even if I should, given we want to be able to subsequently deploy each project onto QA, Test, then Prod.
July 2, 2019 at 11:36 am
Any ideas people?
July 2, 2019 at 12:12 pm
Any ideas people?
No offence, but this task would seem to be beyond your current level of SSIS capability. There is quite a gulf between what you know and what you need to know to complete this task well. I'd suggest that you either
a) Take time to learn SSIS properly, or
b) Find/pay someone else to help.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
July 2, 2019 at 1:20 pm
Forget it people, I've got someone to do it manually. No offence taken.
July 2, 2019 at 1:22 pm
Forget it people, I've got someone to do it manually. No offence taken.
Glad you got there in the end. If you didn't, it would be worth file having the person who did it show you how they did; then you know for future reference.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
July 2, 2019 at 3:36 pm
No, he's importing package by package, as I myself had been shown. I could show him the link you provided me but he'd have even less chance of understanding it with English as a 2nd language than I have with SQL Development as a 2nd skill.
Having reviewed it with fresh eyes I can see it how it allows import of multiple packages but I should have also asked whether I get a separate ISPac file as output, ie the ability to deploy separate packages to separate servers. Not knowing whether that would get a simple yes/no, it just worked out less toothache to have him hand-crank each import and free me up for higher-up stuff.
We live and learn 🙂
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply