October 21, 2022 at 10:19 am
I know it is best practise to use the sproc, [SSISDB].[catalog].[set_environment_variable_value] to update existing Environment Variables.
However, can somebody explain why I can't just run UPDATES on the [SSISDB].[internal].[envrionment_variables] table?
What's the risk here and how is it any different from updating the old SSIS_Configrations table when using the old package deployment method?
It's faster and easier to mass update variables with a single UPDATE, than create a CURSOR to loop through and run the SPROC.
I have scripted a process to get all package and project parameters in a project and add them to three Environments (Test, UAT, Live), link each environment to the Project, Set the Environment Variables Value to the runtime package/project parameter value, and set all SSIS job steps to a specific environment.
So I now have 3 environments all with the same run time parameter values. I now want to update my UAT and Live Environments so their variables point at different paths or servers etc. I could do this very quickly with a bunch of update scripts. Why do I need to call that SPROC for each variable update which will then need calling inside a Cursor to do bulk updates?
October 22, 2022 at 11:10 am
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply