Persisting Package Variables

I was able to write successfully a Script Task to set the values of several package variables. But when the execution completes, the variables still contain values which were specified by default.

What I want is a method of persisting the values assigned to a variable through a script. I believe this was possible in DTS

The variable is not saved, because you have not saved the package. There is no way to do this really, so for anything you wish to persist between package executions you should store externally. If you want to see the value of variables during execution then use a breakpoint and drag the variables to the watch window. You do not see the value in BIDS because the package loaded in BIDS is not the same instance as that being executed. When you execute the package is saved, and a copy loaded into memory of the execution host. The copy in BIDS remains where it is as the debug copy.

In DTS when executing through Enterprise Manager it was the same copy, so you could see the value of variables post execution. The values were still not saved though, it was just a factor of you having only one instance of the package in memory. If you were executing through DTSRUN and variables changed they did not get persisted, as the package was not saved. The changed copy was thrown away once execution completed.

Persist ConnectionString

Hello All,

I have changed connection string property of connectionmanger at runtime and saved package.But my new connectionstring is not persisting, i am getting my old connection string after reload package .

ConnectionManager cm = package.Connections[test.ConnectionManagerID];

cm.ConnectionString = @."C:\Test.csv";

app.SaveToDtsServer(package, null,

@."File System\Dupaco Load Next Best.dtsx", "CIRCLE");

How can I save new connection string?.

Please help me.

Thanks

Subin

The ProtectionLevel property of the ConnectionManager will change what and if sensitive information is saved.

Personally I do not like saving sensitive information in a package, I much prefer using configurations. This allows you to keep such information externally, and just by changing the configuartion information between environments you can easily manage this. This mechanism is obviously great for when moving packages between test and production environments for example, but it scales right down to the developer's desktop, so you use the same mechanism throughout.

Permissions needed to run SSIS Package

If one of our SSIS packages fails because of a communication problem with the backend, and the DBA is not available, my boss wants another individual (probably a senior programmer but not an "sa" type) to be able to re-run the job.

What is the "right" way to do this under SSIS\ sql 2005?

TIA,

barkingdog

this link might help: http://support.microsoft.com/kb/918760/en-us