SQLAuthority News – Best Practices for Integration Services Configurations

Best Practices for Integration Services Configurations
by Jamie Thomson

This article explains what SQL Server Integration Services configurations are used for, why you should use Integration Services configurations, and what options you have for leveraging configurations. It will also make some simple recommendations that are based on my experiences of building Integration Services packages in a real-world environment. An understanding of the terms “package”, “Business Intelligence Development Studio”, and “dtexec.exe” in the context of Integration Services is assumed.

There five basic types of Integration Services configurations.

  • XML Configuration File
  • Environment Variable Configuration
  • Parent Package Configuration
  • Registry Configuration
  • SQL Server Configuration

Read Best Practices for Integration Services Configurations

Abstract courtesy : Microsoft

Reference: Pinal Dave (https://blog.sqlauthority.com)

Business Intelligence, SQL White Papers, SSIS
Previous Post
SQL SERVER – Link to SQL Server Book Online – BOL
Next Post
SQL SERVER – Advanced T-SQL with Itzik Ben-Gan – A Dream Coming True

Related Posts

2 Comments. Leave new

  • Hi Pinal,
    In my usage of SSIS usage, I have used and found the XML configuration option to be really effective and neat, second option would be the SQL Server Configuration option.

    Reply
  • Pinal:
    Have you ever had success in abstracting out the usernames and passwords from SSIS packages so that the packages can be developed in a development environment, and then moved into a production environment without changing the package? Have you ever HEARD of this being done?

    it seems the usernames and passwords are included in the package (bad design microsoft), so that the data center is left with two options: (1) edit the package after it’s been QA’d (violates standard QA process of “what we tested goes into production”) or (2) have the same usernames and passwords for both development and production (VERY BAD DESIGN).

    until this can be resolved, we’re using compiled languages for our imports and exports.

    Reply

Leave a Reply