February 7, 2017 at 12:40 pm
Hello, I'm moving to SSIS 2016 from 2008. My question is specific to deployment and configuration. So, all the research online I've read up on talk about the using the new Project Configuration model instead of the old package configuration model that is in SSIS 2008. So the new deployment piece in 2016 seemed pretty straight forward (creating project based environments and deployments and such).
But I'm trying to figure what the new version should be using to store the configs in the DB. 2008 used the package configs and stored the value in the DB and the associated variable/property it applied to. I don't really see a place for storing the configs in the database in 2016. I only see deployment related stuff. Is this more custom now where I'm responsible for creating a config table and storing my own configs? Can anyone advise on what the SSIS equivalent should be and how I'd go about using it?
Thanks,
Strick
February 7, 2017 at 12:52 pm
stricknyn - Tuesday, February 7, 2017 12:40 PMHello, I'm moving to SSIS 2016 from 2008. My question is specific to deployment and configuration. So, all the research online I've read up on talk about the using the new Project Configuration model instead of the old package configuration model that is in SSIS 2008. So the new deployment piece in 2016 seemed pretty straight forward (creating project based environments and deployments and such).But I'm trying to figure what the new version should be using to store the configs in the DB. 2008 used the package configs and stored the value in the DB and the associated variable/property it applied to. I don't really see a place for storing the configs in the database in 2016. I only see deployment related stuff. Is this more custom now where I'm responsible for creating a config table and storing my own configs? Can anyone advise on what the SSIS equivalent should be and how I'd go about using it?
Thanks,
Strick
I'd say that the general rule is that you would create SSIS parameters in your packages (or, at project level). Your parameters can be linked to the values of variables inside environments and include connection manager properties.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 8, 2017 at 4:46 am
Right, but I'm speaking more on values that need to be stored in the DB. I get the parameters part but I need to have parameters that get their values from the database. In the old model you just put them in the SSIS Configurations table and the package would just read the values from there. I don't see a built in equivalent..
We need to have the ability to update a DB configured value on occasion..
February 8, 2017 at 5:07 am
stricknyn - Wednesday, February 8, 2017 4:46 AMRight, but I'm speaking more on values that need to be stored in the DB. I get the parameters part but I need to have parameters that get their values from the database. In the old model you just put them in the SSIS Configurations table and the package would just read the values from there. I don't see a built in equivalent..We need to have the ability to update a DB configured value on occasion..
Environments are stored in SSISDB. Please give an example of something you believe cannot be stored there.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 9, 2017 at 6:01 pm
It's not that I don't think it can be stored there. It's more the power of storing them in the database. Seems like the new way, the admin would have to go to the environment and change each value. With the configs in the database we can both query for informative purposes and update configs in mass by just writing a SQL statement
If Environments are reading from the SQL database that could be an option for us to accomplish the same thing. I'm just very new to the new model in 2016 having jumped all the way from 2008 that I just don't know if something like that exists.
Thanks for you responses!
Strick
February 10, 2017 at 5:51 am
stricknyn - Thursday, February 9, 2017 6:01 PMIt's not that I don't think it can be stored there. It's more the power of storing them in the database. Seems like the new way, the admin would have to go to the environment and change each value. With the configs in the database we can both query for informative purposes and update configs in mass by just writing a SQL statementIf Environments are reading from the SQL database that could be an option for us to accomplish the same thing. I'm just very new to the new model in 2016 having jumped all the way from 2008 that I just don't know if something like that exists.
Thanks for you responses!
Strick
Yes, I know where you are going with that, and maybe it's not so straightforward in 2016.
But you do have options which do not involve GUI work. For example, catalog.create_environment_variable, catalog.set_environment_variable_value and many other related procs are available to you.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply