January 16, 2012 at 10:42 pm
Comments posted to this topic are about the item A script task alternative to a massive SSIS multicast transformation
January 17, 2012 at 9:00 am
Hi Stan, nice article, however I can't really see this as a replacement for the multicast problem mentioned, as that is a problem which should never exist in the first place.
What it does look like a potentially robust replacement for is the File System task as this would be able to wrap up some of does file checking logic and keep it out of the Control Flow area.
Should mention that error handling using a message box should only be used in a demonstation scenario. If this was a scheduled package which behaved like this then it would stop processing as it waited for the phantom desktop user to click OK!
January 17, 2012 at 9:37 am
I'm not a fan of this. Aside from it being a maintenance issue (editing the SSIS package every time a new folder is needed or removed), you could at least use a for each task and iterate over a list of directories. Inside of that loop, you could use expressions within a file task to copy it around.
January 17, 2012 at 10:00 am
To be honest, the only reason I wrote this is because somebody responding to one of my previous articles asked how it could be done.
Just because something can be done doesn't mean it should be done, but sometimes it's fun to do it anyway.
January 17, 2012 at 10:42 am
Fair enough. I feel the same way about Powershell.
January 17, 2012 at 12:16 pm
Obs (1/17/2012)
I'm not a fan of this. Aside from it being a maintenance issue (editing the SSIS package every time a new folder is needed or removed), you could at least use a for each task and iterate over a list of directories. Inside of that loop, you could use expressions within a file task to copy it around.
It's still good as a teaching exercise. In practice it might be better to have a scratch location for the master and then read the destinations from some table. If you are going in for the script task (VB or C#) then take a closer look into the File I/O objects. I seem to remember that you can specify overwrite or not.
ATBCharles Kincaid
January 17, 2012 at 1:03 pm
I'd definitely go with a For Each Loop and use the File Copy Task. I'd either read from a database table or configuration file. That way you don't have to touch the SSIS package when you have to change the copy locations. Honestly, I hate having tasks buried in code when there are already SSIS components available to use. I find having to crack open the code editor a PITA, and even more annoying when the developer doesn't include comments on what the code is doing and why.
Mwise
January 17, 2012 at 1:19 pm
Charles Kincaid (1/17/2012)
It's still good as a teaching exercise. In practice it might be better to have a scratch location for the master and then read the destinations from some table. If you are going in for the script task (VB or C#) then take a closer look into the File I/O objects. I seem to remember that you can specify overwrite or not.
Perhaps as a "How to make this better" exercise
January 17, 2012 at 2:47 pm
Charles Kincaid (1/17/2012)
...In practice it might be better to have a scratch location for the master and then read the destinations from some table.
I like this idea. While reading the article, this is what stood out to me as an obvious way to improve on the package.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 18, 2012 at 2:04 am
nice article, How about just writing a file to the single location and then use a batch job to copy it to the diffrent folders where ever you want. may be we can include this in another step of the job that we call the ssis package.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply