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)
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.
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.