Home Dashboard Directory Help
Search

Execute Package Task doesn't support SSIS Package Store by SteveOLAP


Status: 

Closed
 as Won't Fix Help for as Won't Fix


2
0
Sign in
to vote
Type: Suggestion
ID: 307862
Opened: 10/31/2007 2:46:31 PM
Access Restriction: Public
0
Workaround(s)
view

Description

When defining the connection for an Execute Package Task, there's no apparent way to specify the package's (i.e., child's) existence in an *SSIS Package Store* (not MSDB or File System) in a manner similar to what we'd do with DTEXEC and a Master pkg: "\File System\Child".

Sure, one could build an expression that produces a fully qualified path to where the SSIS Package Store typically points to, but that defeats the flexibility offered by msdtssrvr.ini.xml. It would be nice to 1) change the registry on remote servers to point to this XML file on a central server, and 2) use the XML file's ability to redirect SSIS Package Store locations. The payoff would be if my UNC-like reference to "\File System\Child" in the Execute Pkg Task connection manager was automatically insulated from such redirects!! Again, remote servers would point to the XML via their registry setting; the XML would point to package locations that could be changed as desired from our central XML file; our connections wouldn't be the wiser!

Master > Child pkgs are great. So is the SSIS Package Store. It's a crime they don't work together.
Details
Sign in to post a comment.
Posted by Microsoft on 11/11/2010 at 4:38 PM

Thank you for contacting us. After analyzing this issue and prioritizing it in the context of our current development plans, we have found regretfully that it does not meet the bar to be included in an upcoming product release. We are encouraging customers to use project reference in EPT; we hope you are able to use that as a workaround.
Your feedback continues to be invaluable to us and we take all your communication seriously. Please continue to contact us with any questions, suggestions and issues as they arise.

     The SSIS Team
Posted by Microsoft on 4/25/2008 at 2:20 PM
We have determined that we will not be able to include a correction for this issue in the current release. We have moved this issue forward to be considered for inclusion in the next release. Thank you for your submission and support of SSIS.
Sign in to post a workaround.