Coding in package, good or bad?

  • I am told that it is considered best practice to use as little as possible coding in a package; that would limit the use of the Execute SQL and possibly the OLE DB Command task.

    Is this correct? We got into this because in a package through a Script task a function is called(T-SQL) where a table is build which in turn is used in further steps. This calling of this fucntion takes a long time, we're talking days here, when processing with a real production load. I suggested to skip the function calling and use the script in the package itself to buil the table. I would think function calling will take more time then directly executing code.

    Again, what is the best approach here? Any website with best practices on using SSIS somewhere?

    Greetz,
    Hans Brouwer

  • I think this is still being debated and I'd be comfortable with either approach as long as it was documented well. The call from the script package means you have to debug this in two places and know to look back at the database. If you are calling something that can be completed in the SSIS package, I'd do it there. You're more loosely coupled and then it's self contained. In case the server moves or something you're ok.

    The downside is if the function changes, you need to change it in two places.

  • Tnx for your insights, Steve.

    Greetz,
    Hans Brouwer

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply