Post reply

SSIS Properties

  • February 2, 2011 at 9:00 am

    #1281508

    Hmm. Had to go look here: http://msdn.microsoft.com/en-us/library/cc895212.aspx

    Beginning of the article ...

    1. The /SET option of the DTExec command prompt utility.

    2. Property expressions.

    3. Package Configurations.

    In essence, these three methods let you modify the values of package properties (like connection strings, variable values, network drive paths, etc) each time you run the package, without the need to edit the package in Business Intelligence Development Studio (BIDS).

    Further down ...

    #Consider using the indirect method whenever possible, as you won’t need to edit the package if the location or name of the configuration file change. With this method, the path and file name are stored in an environment variable.

    #If you find that creating environment variables is too intrusive for your scenario, consider using the direct method. But be aware that changes to the file location may trigger changes to the package, or force you to usether options, such asthe /CONF switch on DTExec command line.

    #You can override the configuration file path and name from the DTExec utility command line by using the /CONFIGURATION option. This option only affects the package being called from the command line; it does not affect packages executed via an Execute package task from a parent package.

    So, is it this last line the question is referring too? Because reading the article as a whole left me thinking that I could make changes.

  • February 2, 2011 at 10:18 am

    #1281547

    Koen (da-zero) (2/2/2011)

    Carlo Romagnano (2/2/2011)

    Koen (da-zero) (2/2/2011)

    paul s-306273 (2/2/2011)

    So, is the correct answer 'FALSE'?

    No, it is TRUE.

    You cannot use the /Set or the /Connection option to override single values that are also set by a configuration.

    OK, What is the use of /Set or the /Connection option? :w00t:

    Override values that are not set by a configuration 😀

    And that's all:exclamation: 🙁

    The next bit

    Or you can alter the connection string to the configuration table. If you point the connection string of the config table to another config table, you can change the configurations from within the job.

    is explicitly NOT possible, the relevant words in BoL are

    You can use the /ConfigFile option to load additional configurations at run time that you did not specify at design time. However, you cannot use the /ConfigFile option to replace configured values that you also specified at design time.

    This amazed me;-). Especially since those words follow other words that strongly suggest that you can override anything in the config. And even more so because specifying a config did what you would expect in SSIS 2005. MS have reduced flexibility here, and I think it's a silly backwards step.

    Tom

  • February 2, 2011 at 10:26 am

    #1281551

    Thanks a lot,

    Now I understand, though the documentation is confusing.

    Does anyone has at hand a small sample in order to try it. Even if it sounds well documented I would prefer to have an exercise at hand in order to support the knowledge with practice.

    Regards,

    Iulian

  • February 2, 2011 at 11:24 am

    #1281580

    Tom.Thomson (2/2/2011)

    The next bit

    Or you can alter the connection string to the configuration table. If you point the connection string of the config table to another config table, you can change the configurations from within the job.

    is explicitly NOT possible, the relevant words in BoL are

    You can use the /ConfigFile option to load additional configurations at run time that you did not specify at design time. However, you cannot use the /ConfigFile option to replace configured values that you also specified at design time.

    This amazed me;-). Especially since those words follow other words that strongly suggest that you can override anything in the config. And even more so because specifying a config did what you would expect in SSIS 2005. MS have reduced flexibility here, and I think it's a silly backwards step.

    Wait. Wut?

    Did I interprete the following line wrong?

    Because the events occur in this order, you can dynamically redirect a configuration by using the /SET command-line option to change the configuration string.

    :ermm:

    And the award for the most confusing documentation goes to ...

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • February 2, 2011 at 11:56 am

    #1281593

    Koen (da-zero) (2/2/2011)

    Wait. Wut?

    Did I interprete the following line wrong?

    Because the events occur in this order, you can dynamically redirect a configuration by using the /SET command-line option to change the configuration string.

    :ermm:

    I don't know (I'm hopelessly confused too) - but if Andy leonard's answer is correct I think you must have.

    And the award for the most confusing documentation goes to ...

    One of the worlds politicians, probably, or maybe a lawyer; but if we eliminated all those confusing parasites, that would leave MS as a very strong contender.

    Tom

  • February 2, 2011 at 4:24 pm

    #1281662

    Tom.Thomson (2/2/2011)

    One can only wonder whether the authors are doing their best to confuse!

    The MSDN/BOL/Etc.. says:

    "However, you cannot use the /ConfigFile option to replace configured values that you also specified at design time."

    Seems clear.

    You can Add New Values, but you can not replace values that are added AND specified at design time.

    Since you can add a property with no value at design and runtime, this makes things very clear to me. I would sudder to think how confused people would be if this change from the 2005 behavior was not documented at all.

  • February 2, 2011 at 4:28 pm

    #1281665

    OCTom (2/2/2011)

    A 50/50 shot on groundhog day. Good guess.:-D

    This was an awesome Groundhog Day question.

  • February 3, 2011 at 10:37 am

    #1282030

    Thanks for the question, things like this are what usually causes problems for people in an upgrade.

  • February 4, 2011 at 12:41 pm

    #1282654

    The dtexec doc states the following:

    You can use the /Set option to change the location from which package configurations are loaded. However, you cannot use the /Set option to override a value that was specified by a configuration at design time.

    We want to do what the first sentence says. Using /Set can change the package configuration used by the package (similar to in 2005 we used the /CONFIG switch.)

    But I cannot get the syntax correct, and I cannot find any examples out there. Here is our command:

    dtexec /DTS "\MSDB\TestSET" /SERVER . /set \Package.Configuration[TestSetConfig].Properties[ConfigurationString];C:\SSISPackageConfigurations\testSET2_dtsConfig.xml

    Can anyone see what we are doing wrong? I am guessing the propertyPath syntax is wrong (perhaps because Configuration is a collection?). Or are we mis-interpreting the MS docs?

    thx,

    jg

  • February 4, 2011 at 3:05 pm

    #1282735

    Hi Gmby,

    I don't override configurations at the command line, but what about pluralizing the package collection name: \Package.Configurations?

    Andy

    Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics

  • February 7, 2011 at 8:30 am

    #1283151

    Thanks Andy, I've tried that. Still receive the same error message:

    Description: The package path referenced an object that cannot be found: "\Package.Configurations[TestSetConfig].Properties[ConfigurationString]". This occur

    s when an attempt is made to resolve a package path to an object that cannot be found.

    I am really wondering if the docs are misleading. I cannot seem to find any examples. I wonder if we are the only ones using config files in this fashion? We have multiple test environments on one SQL instance (2005), so we use the /CONFIG switch to point to different XML package configurations at runtime.

    Am going to test using tables for package configs with the /CON to change values at runtime. If that works and we cannot find the proper syntax, it might be the quickest refactoring effort for us to upgrade to 2008R2.

    thx,

    jg

  • February 7, 2011 at 9:13 am

    #1283200

    gmby (2/7/2011)

    I cannot seem to find any examples. I wonder if we are the only ones using config files in this fashion?

    I use them like this for every SSIS package in production becuase of JSOX and Change Control polices.

    We have multiple test environments on one SQL instance (2005), so we use the /CONFIG switch to point to different XML package configurations at runtime.

    Am going to test using tables for package configs with the /CON to change values at runtime. If that works and we cannot find the proper syntax, it might be the quickest refactoring effort for us to upgrade to 2008R2.

    This is exactly why we are not using 2008 in production yet. Our JSOX and Change Control policy does not allow for re-writing or updating the package file when moving from Uat to Prod. We can update the configuration. Since the database and server names are differant in Prod and are set at design time this makes it a lot of fun.:hehe:

    I hope you find an answer. It would be nice to be able to start migrating/using SSIS on SQL 2008. This six year old VS2005 IDE is getting on my nerves 😛

  • February 8, 2011 at 12:09 pm

    #1283959

    I think the command line should always win. Good question - wish it still worked like 2005.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

Viewing 13 posts - 16 through 27 (of 27 total)

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