Post reply

Master/Child configurations?

  • March 2, 2009 at 12:07 pm

    #135131

    I can see that I can have multiple configuration files for a Package, and I know that I can use an evirnment variable to specify them. However, ia there a way that I can set them up as master & child config files? That is, can I have a master config file determine the location and/or name of one or more child config files?

  • March 2, 2009 at 12:11 pm

    #952035

    So...you want to create a configuration file for other configuration files??

  • March 2, 2009 at 12:32 pm

    #952045

    that sounds right

  • March 2, 2009 at 3:23 pm

    #952146

    we have done something similar. Not sure what your goal is but ours was to have a set of configs for each environment (DEV / QA / PROD) with no changes needed to move from one enviro to another.

    This also protects developers from hitting prod data accidentally.

    This is what I did.

    Have a SQL OLE connection manager with the same name used in every package we build. We'll call it "SQL_CONFIG"

    Create an XML config file that sets the connection string property of SQL_CONFIG. and store it in a central location where all SQL servers and developers have access to it.

    Create an environment variable with a path to that xml file. Called MASTER_XML_PATH

    In your package configs make sure there are no existing configs and add a new one pick xml type then select use enviro var, and pick MASTER_XML_PATH from the list of enviro vars (may need to restart BIDS if not in list)

    It will make an indirect XML configuration and make sure it's the first one in the list.

    Then setup a SQL config using the connection manager SQL_CONFIG.

    You can make multiple XML config files with the connection string prop pointing to different servers and set the environment var for the environment to point to the proper location of the SQL configs.

    For example I have one of the XML configs pointing to the data source of (local) the environment variable used by developers that have there own sql servers running point to this xml doc. This way when they open the package it points to the set of configs they have locally. When it is deployed and running on the server the evironment variable points to a different xml doc which tells the SQL_CONFIG to look at the production server for the configs.

    Downside is having to maintain and keep all configs in sync. but once all packages have been converted to the new system there is little to maintain.

    let me know if you have any questions. - tom

    It's easy to understand but hard to explain clearly

  • March 10, 2009 at 4:35 pm

    #957148

    Can this be made to work for Config files as files or only when they are stored in SQL?

  • March 10, 2009 at 4:43 pm

    #957151

    the problem with that is the xml configs don't use a connection manager.

    The whole idea here is that a single connection manager would control access to the configs.

    I'm not sure at the moment if there is a way around that.

  • March 10, 2009 at 5:03 pm

    #957157

    That's what I was afraid of.

    Thanx

Viewing 7 posts - 1 through 6 (of 6 total)

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