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.
Related
Usually, in a dtsx Standard Report, there is a column "Message Source Name" that indicates which dtsx threw the error or raised the event.
Now i get "Transact-SQL stored procedure" and of course I don't have such a dtsx.
So, question #1 is: Where should I go to check the error?
Besides, the error is: An error occurred while setting the value of a property "InitialCatalog". The error returned is 0x80020009. The connection string components cannot contain unquoted semicolons....
My dtsx were doing fine and I was publishing dtsx on a regular basis with no problems. Then, I changed the name of a ConnectionManager and took care of changing this name wherever it appeared.
After this fateful move, I cannot manage to restore the previous situation. Even rollbacking all changes through TFS and going back to the previous names doesn't solve the matter.
I checked also the environment I am using and the configuration of the job that launches the dtsx, to no avail.
If I execute the dtsx on my development machine, from visual studio, it works fine. The problem arises in production enviroment when I use the job configured with the environment. In the project configuration and in the environment configuration I don't see what an "unquoted semicolumn" could be.
The value of the connection string that is indicated as having an error looks like:
Data Source=11.1.1.11,1111;Initial Catalog=MyDB;Provider=SQLNCLI11.1; Integrated Security=SSPI ;Auto Translate=False;
Question #2 is: Where could this connection string with unquoted semicolon be?
Thx.
With much effort I managed to find an answer to Question #2:
I am using parametrized connection managers, so I have a project parameter (let's call it PP1) in my dtsx with the connString.
During configuration of the SSIS project I need to give a value ONLY for the parameter PP1, and NOT for the connection string.
What I did wrong was to give the Environment Variable with the connString to the Property "Initial Catalog". Therefore, SSIS was lamenting of the presence of ";" (the ones in the connString) in the InitialCatalog.
I have an SSIS 2008 package.
I have 3 user variables in the package. One is for an the environment, one is for the path for an executable, and the other is part of a message for an email.
I have a Script Task that sets the variable for the path (strAppPath) based on the environment variable.
strAppPath is used in an expression for the Executable property of an Execute Process Task. The job fails stating that the executable path for the Execute Process Task is not set.
I'm assuming that it is checking this path before the Script Task sets the variable.
Is there a way to work around this?
Right click on your Execute Process Task and select Properties. In the properties window, you will have a DelayValidation option that is currently set to False Flip that to True.
What is happening is that when the package starts, it goes through a validation phase to ensure everything is kosher before it begins (no need to start processing if something is broken). In your case, that full validation is not desired as the Execute Process Task won't be valid until right before it's time to run. The validation will occur, just that it is delayed until it is time for the task to begin. Make sense?
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 want to add a parameter to a step that runs an operating system (CmdExec) in SQL Server Agent. I have searched everywhere and asked my coworkers and none of them had tried it before. I have attached a picture of the screen. I was thinking that I might be able to add the parameter (file path) after the .exe statement, but wasn't sure.
I thought the following might work:
Executable Path Parameter Path
C:\MyProgram\MyApp.exe E:\AppInfo\Client\Config.txt
This is on a production server and I didn't want to break anything if this isn't correct.
Thanks!
Yes You can use parameters, so your command would be:
C:\MyProgram\MyApp.exe E:\AppInfo\Client\Config.txt
If there is a space in the name don't forget to use quotes as specified in tip in screenshot:
"C:\My Program\MyApp.exe" "E:\App Info\Client\Config.txt"
Since You want to try it on production server, consider testing your configuration and software on test environment first. If You doubt that this will work, You can set job to execute only this single step to make sure it will work as expected.
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.