![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
#3
| |||
| |||
|
|
I'm really confused about the functionality of SQL (and files) configurations in SSIS packages. Unless everything is configured exactly perfectly, SSIS seems to just progressively try other options without any indication. It appears to me that DTExec does the following: try to use a command line configured config file, if it doesn't exist (or it's an UNC path), silently ignore, without even indicating it was attempted... try to use any design time configuration (files, SQL, etc), and if they don't exist, silently ignore without even indicating they were attempted... just use values defined in the package at design time. For SQL config, I would expect to be able to create a SQL config group of settings, copy that config table to different environments, changing values where appropriate, and then create a SQL Agent jobs to run the package. In that job, I would want to change the config table connection (server/database) with "set variables" to change runtime behaviour and pull data from the appropriate environment. However, what seems to be happening is that the current configuration settings in the package are used get the SQL config, and THEN the command line set commands are being applied, so any attempted changes to the config data source are useless. could somone point me to a good reference that CLEARLY describes what sequence of events happens during a DTExec run of an SQL package? I need to know the following: what rules are used when looking for and applying configs applied from command line or design time. when are set variables applied when are configs applied explain why do configurations on the command line seem to be ignored if a config is already defined in the package at design time. explain why are defined configuration files that don't exist simply go out in a whimper, with no indication that they were or were not used. |
![]() |
| Thread Tools | |
| Display Modes | |
| |