We have a SSIS job called ExportData and it accepts the 'ExportType' Parameter. The ExportType parameter can be 'schedule' or 'unschedule'.
I created the Variable called '#ExportType' and created the SSIS Configuration and expose the variable in the Configuration file and called it 'ScheduleConfig'. I copied that file and change the value to 'unschedule' and called it 'UnscheduleConfig'.
I created the SSIS Job in the SQL Server 2008 and set up 2 steps for both 'Schedule' and 'Unschedule'. I attached the correct config file for each Step. But whichever step I run, it always execute 'Schedule'. I am sure and double checked the Config files and Steps.
How can I run 2 different jobs with 2 different configuration files?
I did try by using the SetValues method and it doesn't work too.
I suggest you not store #ExportType in an SSIS Configuration. You can override the value from the DTEXEC command line by adding a SET switch similar to:
/SET "\Package.Variables[ExportType].Properties[Value]";Schedule
You can use the same PackagePath above to override this variable value in the SQL Agent Integration Services Job Step Type on the Set Values tab.
Hope this helps,
Andy
If I understand your requirements correctly. here is a sample package created in SSIS 2008 R2 and does what you are looking for. The sample uses a single package, which is executed under two different SQL agent job steps and both the steps use a different copies of the same configuration file. The configuration files hold different values for the variable used inside the package.
Created a sample SSIS package named SO_10177578. Within the package, created a package variable named ExportType of data type String. Also, placed the Execute SQL Task on the Control Flow tab. This task will help to identify the value being passed to the variable ExportType.
Added the OLE DB connection to a sample database and named the connection as SQLServer. I chose to use SQL Server authentication for this connection manager.
Within the SQL database, created a table named dbo.ExportData with the following strucutre. Id column is a identity column.
The table doesn't contain any data to begin with. This table will be populated with data when the package is executed.
On the SSIS package, clicked on the SSIS menu --> selected Package Configuration option. On the Package Configurations Organizer dialog, selected the Enable package configurations checkbox and clicked on the Add button. Created a new package configuration of the type XML Configuration file. Selected a path to store the file.
Added the Value property of the variable ExportType and the ConnectionString property of the connection manager SQLServer to the configuration file.
On the Execute SQL Task, selected the Connection to be SQLServer and set the SQLStatement property to INSERT INTO dbo.ExportData (PackageName, ExportTypeValue) VALUES (?, ?)
Configured both the parameters to the appropriate variables available on the package. Now the package is ready for deployment.
On the database server's SQL Agent node, created a new SQL job named Test_ExportData. Owner field information is removed to hide sensitive information.
On the SQL job's Steps page, created two steps named Step_01 and Step_02.
Step 1 is configured as below with the package being stored in the path c:\temp\SO_10177578.dtsx.
Copied the package configuration file created using the package and changed the value for the variable ExportType to Schedule. Named the configuration file as ScheduleConfig.dtsConfig. Screenshot shows only part of the configuration file to hide sensitive connection string information.
In step 1 of the job, referred the newly created package configuration file from the path c:\temp\Test\ScheduleConfig.dtsConfig.
Step 2 is configured as below and it uses the same package stored in the path c:\temp\SO_10177578.dtsx as used by step 1.
Copied the package configuration file created using the package and changed the value for the variable ExportType to Unschedule. Named the configuration file as UnscheduleConfig.dtsConfig. Screenshot shows only part of the configuration file to hide sensitive connection string information.
In step 2 of the job, referred the newly created package configuration file from the path c:\temp\Test\UnscheduleConfig.dtsConfig.
Now, both the steps are configured. Executed the new SQL agent job.
Queried the table ExportData. You can notice that the package was executed twice and each execution in the SQL agent job's steps used the appropriate configuration files specified on the steps.
Hope that helps.
you cant do that. The SSIS wont read the new configuration.
You need to call the package twice, one time with config file A and one time with config file B. On each config file you will have the #ExportType variable set to 'schedule' and 'unschedule'.
You can only set a parameter once. Even if you use DTEXEC with the /Config option for example you CANT overwrite a parameter that is already set
Related
I have an SSIS package with several data flow tasks. Each one imports a flat file into a table in my DB. I have created a connection manager for each underlying flat file. The package works just fine if all of the files exist. However, even if one of the files is missing, the entire package fails. I don't want this behavior. For whatever files that exist, I want my package to import them. For those that don't exist, I want SSIS to simply ignore them. At least one of the files will always exist. How do I achieve this behavior? I have seen some solutions that involve either scripts or file control tasks, but I'm not sure which is appropriate for my situation.
my solution is
1. make a Script Task for checking the path file:
SSIS Script task to check if file exists in folder or not
2. ValidateExternalMetadata set to False in the source properties
3. link the Script Task with next step if skip and create a Constrain and Variables connection with if the file exist
I created a simple SSIS package to import a flat file (.txt) into a database table. Tested that and it works perfectly. Since I have several files to import, I added a foreach loop to go through all the files, added the variables as recommended in several examples found on the net but now my flat file connection manager returns an error of "A valid file name must be selected." and the package will not run. I have so far been unsuccessful in finding the solution for this issue and would appreciate any suggestions by the SSIS gurus of this forum. Many thanks in advance!
Here is what I have in the way of variables:
SourceFileFolder which is the path to the folder that contains the files
FileName a string containing one of the names of the files I am seeking to import
SourceFilePath which is an expression driven variable that incorporates the previous two variables concatenated together. I can click "Evaluate Expression" and copy and paste it into windows explorer and open the file
ArchivePath which is an expression driven variable that creates the path to archive the file to once it is processed.
As the message says this is related to your connection manager not gathering the connection string. This can be handled using the following:
First of all clear the expression on the SourceFilePath variable.
With your Foreach Loop Container, set it up as follows:
This will use your variable SourceFileFolder as the Folder, you could also just hardcode the folder name C:\ for instance. Also make sure your folder is qualified correctly, I.E. make sure it finishes with a slash C: won't work but C:\ will work.
Next you need to map the fully qualified name to your other variable SourceFilePath
This should now store the full name of the file the loop has found into the SourceFilePath variable. For Instance C:\File.txt, you can now use this as a connection string expression on your file connection manager.
Under the properties of the connection manager make sure the expression is set to ConnectionString and then use the SourceFileName variable.
ALSO MAKE SURE DELAY VALIDATION IS SET TO TRUE
This hopefully should mean you can loop through the files.
I have a parent pkg that calls a few child pkgs. For each child pkg I have a sql agent job that will override some Conenctions values as in dtexec, where you can use the handy /Conn[ection] to make the pkg configuring in a different way simply pointing to a diff SQL SSIS Conf table (common pattern). The problem is that Execute Package Task (called by the parent) does not have any option rather than calling the child pkg itself (I cannot call Execute Package Task passing smth like /Conn[ection] as I can do with dtexec) so a natural coice would be using Execute Process Task to call dtexec on Child pkg with a appropriate /Conn[ection] setup. Based on your experience are there any drawbacks/issues to consider when using Execute Process Task DTEXEC rather than the Execute Package Task or they are the same thing at the end...?
Mario
The way that I've seen this handled is to create a variable to hold the folder path and variables to hold the package names for each child package. These should be added to the Parent Package.
Then in your connection manager for the child package, you can write an expression to set the connection string dynamically. Right click and select properties for the connection in connection manager, then concatenate these two variables.
Expression Code:
#[User::sPkgFolder]+ #[User::sPkgFilename]
In addition you can set up a XML configuration file and set the variables via the XML file so that as you move the packages from environment to environment you don't have to manually change the code base, but only need to change the value of the path in your configuration file. You can also set up as many variables as need to hold all your child packages.
As already exaplined by SWilliams you can send parent package variables down to a child package using the execute package task, then in the child pacakge you can use this variable in an expression to set the connection. This is far less convoluted than using SQL Agent, configurations etc. and has the added bonus that if you run it in parallel it won't get confused.
I have an ssis package...which read data from fixed-column-width text file into DB table.
And I am modifying an existing ssis package.
I have a flat file source...and flat file cnnection. When I try to edit the flat file connection...using "flat file connection manager editor"..., under "general" part...even if I select different filename..it's not getting reflected.
OR...select the properties window of "Flat File Connection" - once I change connection string and click "save" of visual studio...it rollback
Help me please.
Pulling a useful comment into an answer...
It's possible that that Connection string (the file path, name) is set from an expression/user or project parameter.
To check, right-click the flat-file connection manager and go to Properties, then check Expressions to see if the ConnectionString is set from a variable such as #[User::MyFileConnectionString]
That would cause this behavior of it seemingly "un-doing" after you change it manually.
Is it possible you don't have access to the package itself? Right clicking on the file icon in the Connection Manager below and selecting 'Rename' and then renaming it right there and then saving the package should work.
Is there anything similar to global variable in SSIS? I have 4 variables (FromAddress, ToAddress,...) which will be used in all packages (32).
So if I can set them only once it will be very easy to use in all packages and will save my time.
Please advise.
SSIS has variables that can be global to a package, but to span multiple packages, I can think of the following options
Passsing Variables
Have Main Package define a variable and pass the value as a parameter to all packages that it calls. Call the variable the same name in all packages for easy identification.
Config File
Use the same SSIS configuration file across packages and store the value in there.
Environment Variable
Use a windows environment variable that is read from other packages
Registry Value
Store in Windows registry and read for each package - make sure you store under a tree that all packages can see otherwise you may run into permissions issues. Eg HKLM
Database Lookup
Store the value a table structure.
You can create local variables in your scripts. Any variable you create in a script is local just to that script. You can also create global variables (via the Variables slideout window) which can be scoped for the entire package, or a subset of the package.
You could use Package Configurations (using either a DB, XML file, environment file or registry setting) to hold these values and each of the 32 packages can reference the same configuration, rather than have to set up the variables in each package,
You can use a configuration database to retrieve values like that across multiple packages.
Using package configuration, you can simply do it. There is a great answer by #RodWall
https://stackoverflow.com/a/35069635/1468295