Calling Windows Environment variable into the Master package in Project Deployment model

Question

Calling Windows Environment variable into the Master package in Project Deployment model

Viewing 6 posts - 31 through 35 (of 35 total)

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

Guitar_player SSCrazy Points: 2991 More actions · Answer 1

nope ...but on click of the 'Parameterize' option, we will get the chance of selecting our own property i believe but i just have selected the connectionstring instead of other properties

Phil Parkin SSC Guru Points: 246959 More actions · Answer 2

Guitar_player (2/9/2015)
nope ...but on click of the 'Parameterize' option, we will get the chance of selecting our own property i believe but i just have selected the connectionstring instead of other properties

In 2014, it's possible to parametrise the following:

ConnectionString

Description

InitialCatalog

Name

Password

RetainSameConnection

ServerName

UserName

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

Guitar_player SSCrazy Points: 2991 More actions · Answer 3

Guitar_player

SSCrazy

Points: 2991

February 9, 2015 at 5:06 am

#1776343

Hmm...

Guitar_player SSCrazy Points: 2991 More actions · Answer 4

Hey Phil,

please check this link

https://ask.sqlservercentral.com/questions/117983/cannot-use-a-sensitive-project-parameter-on-ssis-2.html

i am looking exactly for the same !!!

Phil Parkin SSC Guru Points: 246959 More actions · Answer 5

Right. As this is dragging somewhat, I set up a test to make sure it works. Here is what I did:

1) Create a package containing a single trivial ExecuteSQL task (select getdate()).

2) Configure the connection to use a SQL Server user (not a trusted connection).

3) Parametrise the connection – password only – and make the parameter sensitive. Do not enter a value.

4) Set the package and the project to "Don't Save Sensitive"

5) Build and deploy to SSISDB.

6) Create an Environment and add a reference to the environment from the deployed project.

7) Create a 'sensitive' string parameter and set its value to the password of the user from (2) above.

8) Configure the package to map the environment password parameter to the package password parameter.

9) Execute the package, using the environment you just created.

Worked for me.

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

Lempster SSCoach Points: 15651 More actions · Answer 6

Phil Parkin (2/10/2015)
Right. As this is dragging somewhat, I set up a test to make sure it works. Here is what I did:
1) Create a package containing a single trivial ExecuteSQL task (select getdate()).
2) Configure the connection to use a SQL Server user (not a trusted connection).
3) Parametrise the connection – password only – and make the parameter sensitive. Do not enter a value.
4) Set the package and the project to "Don't Save Sensitive"
5) Build and deploy to SSISDB.
6) Create an Environment and add a reference to the environment from the deployed project.
7) Create a 'sensitive' string parameter and set its value to the password of the user from (2) above.
8) Configure the package to map the environment password parameter to the package password parameter.
9) Execute the package, using the environment you just created.
Worked for me.

Sounds like the basis for an article Phil...;-)

Regards

Lempster