Passing parameters into config file
-
Hello all,
I am going to try and explain what I am looking to do here, so please bear with me :-).
I have several SSIS packages that run off of config files. Each package, as of now, has a dedicated config file which makes deployment prone to human error. What I would like to do is have one dedicated config file for all packages and pass variables into the config file.
I have researched environment variables, but I am concerned about security issues and creating extra steps. I am looking to do something like this...
<ConfiguredValue>Data Source=[User::DataSource];Initial Catalog=[User::InitialCatalog];Provider=[User::Provider];Integrated Security=[User::IntegratedSecurity];Auto Translate=False;
So, I am guessing that I can pass these parameters FROM a SQL Agent job into the SSIS package and into the config file. Is this possible?
Thank you all in advance for your time.
The are no problems, only solutions. --John Lennon
-
SQLTougherGuy (4/6/2016)
Hello all,I am going to try and explain what I am looking to do here, so please bear with me :-).
I have several SSIS packages that run off of config files. Each package, as of now, has a dedicated config file which makes deployment prone to human error. What I would like to do is have one dedicated config file for all packages and pass variables into the config file.
I have researched environment variables, but I am concerned about security issues and creating extra steps. I am looking to do something like this...
<ConfiguredValue>Data Source=[User::DataSource];Initial Catalog=[User::InitialCatalog];Provider=[User::Provider];Integrated Security=[User::IntegratedSecurity];Auto Translate=False;
So, I am guessing that I can pass these parameters FROM a SQL Agent job into the SSIS package and into the config file. Is this possible?
Thank you all in advance for your time.
If you are using integrated security, what security issues concern you?
If you are not, you are going to have to put passwords somewhere. Unless you use 'sensitive' variables in SSISDB environments, the chances are that these passwords will be in clear text.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin -
Hi Phil,
If you are using integrated security, what security issues concern you?
I guess my question should be... "What types of security issues will I have to concern myself with using environment variables."
I am using Windows Authentication, so I do not think I need to store passwords. Unless I am mistaken.
The are no problems, only solutions. --John Lennon
-
SQLTougherGuy (4/6/2016)
Hi Phil,If you are using integrated security, what security issues concern you?
I guess my question should be... "What types of security issues will I have to concern myself with using environment variables."
I am using Windows Authentication, so I do not think I need to store passwords. Unless I am mistaken.
Here is a 'sensitive' environment variable. Even I, as creator, cannot see its value. So it's quite secure, IMO.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin -
Unticking the 'Sensitive' check box does not reveal the password, in case you were wondering.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin -
Going to try it with Environment Variables, thanks as always 😀
The are no problems, only solutions. --John Lennon
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply