Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Pass SSIS Object to child SSIS package Expand / Collapse
Author
Message
Posted Thursday, December 19, 2013 12:02 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, November 21, 2014 12:18 PM
Points: 5,438, Visits: 7,606
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... :)

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
Post #1524739
Posted Saturday, December 21, 2013 2:56 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:20 PM
Points: 35,552, Visits: 32,148
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1525296
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse