SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Pass SSIS Object to child SSIS package


Pass SSIS Object to child SSIS package

Author
Message
Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8591 Visits: 7660
blasto_max (12/19/2013)
Thanks for all the tips @Evil Kraig F. I made a child package which will accept a DataSet from a parent package and convert it into a CSV file. Since you mentioned that child packages are inconvenient and are to be avoided, I was wondering if you can see/foresee any problems in my approach ?



Since you asked... Smile

You can't change the metadata of a target CSV Connection at runtime, at least not without third party tools or completely rolling your own script component to do this. So, while this child package will work fine in this particular instance, it's not a re-usable child for another process unless the output CSV is exactly the same. This comes back to the concern of over-coding a solution, at least to me. What benefit is the child package vs. just having it contained within a single parent package?

When I work with SSIS, I typically look at logical breakpoints, not code breakpoints, as to when to move to a new SSIS package. This has more to do with job restarts due to network breakdowns (or other random issues) at a particular step in a series than for code encapsulation.

If you're looking to encapsulate a step series for testing runs (For example, a truncate-load on a particular table without running an entire package) the sequence container allows not only for collapsable organization of multiple code pieces, but rt-clicking on it allows you to execute a container for testing. Very useful.

My general concern with Child Packages is not that they can be fussy to work with, it's that they segregate sections of a process usually with little purpose. As an example, you're called at 2 AM by your DBAs (you're a dev) and your package broke. They send you a lovely .log file and the DTSX package from production (because never trust dev still looks like that) and you crack it open and get to work. You eventually find out the problem is in the child package and now you have to track down the guy on call (hopefully he's not asleep again) and get yet another package offloaded and shipped to you. End of the world? Absolutely not. Annoyance with little to no gain? Usually.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)

Group: General Forum Members
Points: 85937 Visits: 41091
Evil Kraig F (12/19/2013)
SSIS however is awesome for laying out processing methodology and calling sequential procedures with obvious and self-documenting logic pathing, however. There's plenty of other things it can do but I find a single package controlling a complete task to be very easy to read without having to dig through code to find the control pass points or dig through signficantly complex if trees.


Now THAT I agree with. It's also a heck of a lot easier to run things "in parallel" than it is with T-SQL.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search