I'm having a problem transitioning a 2005 package to 2008 - it appears that in 2008, package variables configured to use a Configuration Filter (eg populate from [SSIS Configurations]) will not honor the /SET command provided by dtexec.exe to override a package variable value at runtime.
The issue is documented here http://dougbert.com/blogs/dougbert/archive/2009/04/07/understand-how-ssis-package-configurations-are-applied.aspx
What's the most straight-forward solution for this? I want the old SSIS 2005 behavior where, a package variable is initially loaded from [SSIS Configurations] but I can override it at runtime if I explicitly call /SET
I have a work-around but am hoping for a better solution - I basically have 2 versions of a variable I want ...eg NETWORK_PATH, NETWORK_PATH_CONFIG ...I put an expression on NETWORK_PATH to use the NETWORK_PATH_CONFIG (this variable would be populated from [SSIS Configurations]) if the value of NETWORK_PATH is initially NULL at runtime when the expression is first evaluated otherwise use the value that was provided (presumably by dtexec /SET)
You either use /Conn to change the location of your config settings and have the different settings there or you remove the variable from the configurations completely so that it can be set in the dtexec /set parameter.
If you want to have a default and override then you will have to go with the /conn parameter and change the location of the settings.
e.g.
"C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe"
/File "C:\Path\To\My\Package\Import Types.dtsx"
/Conn Connection1;"Provider=SQLNCLI10;Server=MYSERVER;Database=DB_ONE;Uid=USERNAME;Pwd=PASSWORD;"
/Conn Connection2;"Provider=SQLNCLI10;Server=MYSERVER;Database=DB_TWO;Uid=USERNAME;Pwd=PASSWORD;"
It appears someone thought this was better than the 2005 method. I would like to know his rationale before I hit him.
Related
I am using Visual Studio 2019 Community edition. I was trying to configure and ADO Net Source using SQL Command. However, I need to pass parameters to it. Is there an easy way to inject SSIS Variables into it?
Yes, you can do it, using expression.
Open data flow task, right-click on empty space there and choose "Properties".
In "Properties" window choose "Expressions"
In opened window choose [Your data source].[SqlCommand] and add you variable there in Expression input.
I need to use a variable I get in a Script Task in one package in a Script Task in another package. How can I make a variable with a scope that spans packages? Are there Project variables?
Prior to SQL Server Integration Services 2012, the only way to share a value between packages was to use Parent/Child configuration. You could actually share a value between them without using configurations but it was janky as all get out.
If you have no need of bi-directional communication, then you could have package A (one that computes the value in script task) start package B and use the /SET properties to assign a value to the variable
dtexec /file PackageB.dtsx /Set \Package.Variables[User::SharedVariable].Properties[Value];\"I was computed\"
In a SQL Server 2012 project deployment model, the Configuration concept has been replaced with Parameters. This is a bit more straight forward as you define Parameters and specify whether they are required. The Execute Package Task provides a nice mapping mechanism between local variables and expected Parameters.
In SSIS 2005 and 2008:
Declare a variable - say p as int - at the package level
Call your child package from the parent package.
Now, if you have a script task in the Child package, you can access the variable p like this:
1. Pass ReadOnly variable p in the Script Task Editor of Child package
2. To access the parent variable: Dts.Variables["p"].Value;
Notice, that I have not use "User::p" in any of the above two steps. I find this method straight-forward.
Make sure you do not declare a variable p at the child package level.
So, how does this method work? Think of the basic concept of the scope of a variable. The script task will keep "going up" to find the variable p. Going up means - it will first try to find it at task level, then container level, then package level, then finally at parent package level. (This is a simple explanation - technically each of these levels are containers.)
In SSIS 2012, you can also use parameters to pass the variable in ReadOnly mode. The method described above can also be used in SSIS 2012 with added advantage of being able to overwrite the value of the parent variable.
I'm trying to set up a 'master' SSIS Package in SQL Server 2008 to run other 'child' packages. When developing the 'child' packages we have all the packages sitting on disk so we can easily debug them, so we use file connectors during development and can monitor the progress nicely.
When we deploy, we deploy the child packages to SSIS on SQL Server and then go through and change all the Execute Package Task's to use a location value of 'SQL Server' and set the PackageName. Once done, we deploy the 'master'.
What I'd like to do is use an Expression on the Execute Package Task to set the connection properties so we can configure this dependent on the environment. We have already setup a SQL Server configuration database using a view which checks the host name of the query and returns different values dependent on the query.
You have options. You're in the right frame of mind using expressions, but you might benefit from using configurations as well.
To use expressions, you would need to use a Script Task or Execute SQL Task to return back the list of files you want to work through.
You would either have to assign each returned value to it's own variable that is passed into the expression, or use a FOR EACH loop and work through a list, assigning the location of the child package each time.
The other option is to use configurations. My preference is to use a configuration table inside SSIS. If you have the same list of packages in each environment, you could either pass in the root directory and have an expression use that:
#[User::RootPackagePath] + "\PackageName.dtsx"
Or, you could simply have one record for each child package in the configuration table and that would be passed into the package.
Edit based on comments:
I was successfully able to configure a package to change via configurations to call a package from the file system then SQL.
I only needed to pass the Connection and PackageName for each. With SQL, it want a name from the connection manager (.\SQL2008R2 in my case) and the package name (\Package1). For the file system, PackageName is blanked out and the connection is a FileConnection in the connection manager.
You will have to keep both in the package, but you switch between the two.
I am running an SSIS package in a SQL Server agent job. I have several variables I need to set for production as I develop with development settings and example of this is a log variable which passes a path to use for a text file connection string. I used the "Set Values" UI dialog to set this value and the resulting Command Line for this job step looks like this ...
/SQL "\MyFolderInMSDB\MyPackage" /SERVER "mw-test" /CHECKPOINTING OFF /SET "\package.variables[log].Value";"C:\Logs\Imports\mylog.log" /REPORTING E
There does not seem to be an error trying to set the variable but when I run the job it is logging to the variable defined in the task when I developed it and not the path I am sending in as a variable above. Anyone seen something like this?
Assuming you have pasted your SQL Agent job step information and not retyped it, the problem is most likely due to case sensitivity. Stuff in SSIS is case sensitive so variable names of "log" is different from "Log".
/SQL "\MyFolderInMSDB\MyPackage" /SERVER "mw-test" /CHECKPOINTING OFF /SET "\Package.Variables[User::log].Properties[Value]";"C:\Logs\Imports\mylog.log" /REPORTING E
#Bill's example above also runs into a case sensitivity with the provided path.
Try this: http://www.buildingmeaning.com/?p=171
Looks like you are very close. Probably just changing
"\package.variables[log].Value"
to
"\package.variables[log].properties[value]"
I had to mark the ConfiguredValue as being read from the Executable value in SSIS package and config
\Package\Variable Container.Executables\Variables[User::run_type].Properties[Value]
Otherwise, the static value from the config was being read every time.
I am trying to build an SSIS 2008 solution using TFS 2008. I created a 'TFSBuild.proj' file using the build definition wizard. My build appears to work, but fails at the final step with the error...
(0,0): warning MSB4126: The specified solution configuration "Release|Any CPU" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
I've tried...
Leaving the 'FlavorToBuild' & 'PlatformToBuild' values blank in the 'TFSBuild.proj'
Amend the 'FlavorToBuild' & 'PlatformToBuild' values in the 'TFSBuild.proj' file to various other strings
Any ideas?
Apparently you can't build SSIS project files, out of the box, because they are not in MSBuild format. Great!! - Sarcasm overload.