June 12, 2012 at 11:17 am
After converting to project deployment model, has anyone attempted to reference a package that resides in a separate project, using a project reference? Or is it even possible?
In our previous packages we simply referenced the packages via a file path, but I am now deploying all packages to the server and would like to remove the file path in favor of project references. I suppose I could merge my various projects into one large project and then I could access them, but then I loose the logical separation of projects.
Any ideas, or is further clarification needed?
Thanks
June 13, 2012 at 12:34 am
I don't think it is possible to reference packages outside the project without using file connections.
It would be nice if they added such functionality though.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 13, 2012 at 3:50 pm
Koen, thanks for the reply, maybe you can help with the next part of this quandary then...
Since I can't reference a package that resides in another project I am trying to deploy all my projects to the server and then access them via a server reference...
The problem being that the execute package task does not direct you to the SSISDB to access the Projects catalog, rather it directs you to MSDB (the old package store)
I can import the packages to the package storage but that seems to defeat the purpose of using the SSISDB, where I have my environments setup.
Is there a way to got the SSISDB with an Execute Package Task?
Basically, I a processing department that will be running various packages to load data and process cube, and in order to keep then from having to execute many packages we created one "wrapper" package to call all the needed processing packages.
June 14, 2012 at 12:03 am
Sorry, but I'm still a bit in the dark how this scenario should be handled.
It does indeed look like you can only reference external packages in the MSDB or on the filesystem, which sounds like a huge drawback to me...
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 19, 2012 at 12:39 pm
So for now where are just putting the "project name" at the beginning of the package name, and keeping all packages in one project. This allows for the use of the environments in the server, but does eliminate the ability to have separate projects...
July 15, 2012 at 9:24 am
sqlNinja (6/19/2012)
So for now where are just putting the "project name" at the beginning of the package name, and keeping all packages in one project. This allows for the use of the environments in the server, but does eliminate the ability to have separate projects...
Not knowing how complex these cross-project dependencies are this may or may not work for you. You might want to consider breaking up the projects based on the dependencies. If you have one parent package that runs a few child packages that don't have any other parents (sounds like a dysfunctional family) you could group them in a project by themselves.
If that isn't possible then what you're doing is probably best. The point to the Project Deployment Model is to keep all the dependencies together so you can deploy them in an atomic fashion.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply