February 1, 2011 at 8:45 pm
Comments posted to this topic are about the item SSIS Properties
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
February 1, 2011 at 8:46 pm
I was not sure about the answer. Just guessed it and got it right 🙂
M&M
February 1, 2011 at 11:29 pm
February 2, 2011 at 1:14 am
I think that the answer is FALSE, because the question asks
you CANNOT override a property from the command-line.
Then, the explanation says that
the command line always “wins”
, that means you CAN override a property.
February 2, 2011 at 1:23 am
This was removed by the editor as SPAM
February 2, 2011 at 1:26 am
Not sure about this. Please explain.
The /Conf[igFile] parameter of dtexec
Specifies a configuration file to extract values from. Using this option, you can set a run-time configuration that differs from the configuration that was specified at design time for the package. You can store different configuration settings in an XML configuration file and then load the settings before package execution by using the /ConfigFile option.
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. To understand how package configurations are applied, see Package Configurations and Behavior Changes to Integration Services Features in SQL Server 2008 R2.
and also SET Option
The following shows how to use the /SET option, which lets you change the value of any package property or variable when you start the package from the command line.
Details here: http://msdn.microsoft.com/en-us/library/ms162810.aspx
Regards,
Iulian
February 2, 2011 at 1:59 am
Difficult question, but surely nice to know. Good work Andy!
Regarding the speculations about the correct answer being False, read the following BOL page:
http://msdn.microsoft.com/en-us/library/ms141682.aspx
At the section Understanding How Package Configurations Are Applied at Run Time, the steps are described in which order the configurations are applied.
It says literally:
However, these command-line options do have some restrictions:
* You cannot use the /Set or the /Connection option to override single values that are also set by a configuration.
* You cannot use the /ConfigFile option to load configurations that replace the configurations that you specified at design time.
Furthermore, the section links to a MSDN page with behaviour changes from 2005 to 2008. There is explicitly stated (as mentioned by Andy in the explanation):
In SQL Server 2005 Integration Services, events occur in the following order:
1.The utility first applies the design-time configurations. (Design-time configurations are the configurations that you created and associated with the package when you designed the package in BI Development Studio.)
2.The utility then applies the run-time options that you specified on the command line when you started the utility.
In SQL Server 2008 Integration Services, events occur in the following order:
1.The utility first applies the design-time configurations.
2.The utility then applies the run-time options that you specified on the command line when you started the utility.
3.Finally, the utility reloads and reapplies the design-time configurations.
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.
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 4:24 am
I am thoroughly confused, and must do some more reading.
Here's what MSDN Understanding Integration Services Package Configurations says:
In SQL Server 2008 Integration Services, package configurations are applied twice, before and after applying the options of the DTExec command prompt utility. This should be seen as an improvement, since you can now use the /SET, /CONF or /CONN options of the DTExec utility to alter the original definition of the configurations.
That seems to state quite clearly that you can now (in 2008) do more with the command line than in 2005.
But this is contradicted elsewhere: dtexec Utility says when describing the /configfile option
Specifies a configuration file to extract values from. Using this option, you can set a run-time configuration that differs from the configuration that was specified at design time for the package. You can store different configuration settings in an XML configuration file and then load the settings before package execution by using the /ConfigFile option.
but then goes on to say
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.
Those two statements come one right after the other: "You can change things"; "You can't change things, just add things that you didn't previously specify". One can only wonder whether the authors are doing their best to confuse!
Tom
February 2, 2011 at 5:03 am
So, is the correct answer 'FALSE'?
February 2, 2011 at 5:07 am
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.
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 6:30 am
A 50/50 shot on groundhog day. Good guess.:-D
February 2, 2011 at 6:36 am
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:
February 2, 2011 at 6:40 am
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 😀
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.
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 7:41 am
Thank you Koen (da-zero).
Now, the qotd seems more clear!
😀
February 2, 2011 at 8:20 am
Hi Carlo,
You are correctly confused, as was I. In most applications the command line wins. I researched this change some and there is at least one legitimate use case for the change. That said, I disagree with this change to the SSIS runtime.
In SSIS 2005, developers had the option of storing values inside the package (design-time defaults), in Package Configurations, or overriding values at runtime.
In SSIS 2008, developers lost the ability to override values at runtime if those same values are stored in a Package Configuration. If developers want to store values in a Package Configuration, the values cannot be overriden at runtime; and if developers want the ability to override the value at runtime, they cannot store the using Package Configurations and must override the value from the command line each time (or accept the design-time default).
I don't like the change.
Further, if this is the chosen default behavior for a use case (or set of use cases), I believe this behavior should be a command-line option or package property - defaulted to the current (new) behavior - but "switchable" to the old behavior from the command line or inside the package at design-time.
Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply