2012年3月22日星期四

Anyone else have errors when checking out SSIS package from SourceSafe or TFS?

I get errors when I check out an SSIS package from source control (both Source Safe and TFS) relating to the connection objects where I was not the original developer who checked it in. Is there a solution to this other than altering the connection login\password for every connection object in the package before deploying?

Yes, I do have problems as well when updating CVS.

For SSIS the solution is to use configuration files for your connections and Security / Protection Level property set to "DontSaveSensitive".

For Reporting services and cubes I am still a bit confused.

For reports, As soon as I open them in BIDS, I immediately edit the shared data sources to retype in the account and password. If I do not do it and go to the data page, it will loose all stored procedures parameters :-(

For Cubes, I also revisit the data sources as soon as I open the cube. Not doing so will let you work on your cube and deploy it, however you will not be able to browse, aggregate or process it.

Philippe

|||

The critical item here is to not have the Package Protection Level Property set to Encrypt[Sensitive or All]WithUserKey. That uses the developer's Windows login to encrypt information in the package, so no other developer will be able to work with it very easily, unless they log in with the same Windows account.

As Phillippe said, a common workaround is using a ProtectionLevel of "DontSaveSensitive" and configurations, which also makes it easier to deploy the packages in multiple environments. You could also use "EncryptSensitiveWithPassword" which will mean you have to enter a password for the package before running it, but it will be able to store the passwords inside the package, rather than depending on configurations. The best choice depends on your scenario.

没有评论:

发表评论