Well written article and new way of working with Configuration tables. I like the trigger used to track changes in the configuration table. To me, though, the data and security risks of having all the configurations in one table far out-way a little extra work on my part to manage configuration tables by application and server. I require the separation of production, QA and test data and even separation of data by application. I actually require that the configuration tables be loaded into a separate (non-dbo) schema. This allows me to easily control security by schema. All of this allow the developers to access their own configuration tables for testing but cannot even see the QA and production configuration tables... nor can they see the configuration table for other applications.

The migration of configuration data from test to QA and prod has to go through the DBA, which then modifies the data as needed to update passwords, folders, etc. From what I've seen, configurations are not changed that often so once they are set up, the maintenance and SSIS migrations are fairly simple. We use environmental variables to define which server and development environment the package is running in. This is easy to set up and simple way to allow developers to jump between different development environments.

David