I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.
Related
I have an SSIS Package that as part of the process uses a File System Task to move a file to an archive folder.
The Source is a variable from a For Each Loop. The Destination is a File Connection with the connection string set to a Variable. The variable is static assigned in dev, and pulled from a package config when deployed.
Everything works in VS in the dev environment. I deploy to SQL Server and schedule with a SQL Job. Job fails. Immediately, I think it's a permissions issue but my Proxy has Modify to the destination and read on the source.
I then rewrite the package so the move file is done in a script task using system.io. Deploy that and it works with the same proxy account on the job, so it's not a permissions issue.
I'm happy it works, but want to know why it failed before.
The error I got when it failed was, "File or Directory "\destinationpath" represented by connection "archiveconnectioname" does not exist."
Has anyone any ideas?
I've been working with SSIS reading different files - from CSVs to XLSXs - with no problems. My paths are relative, so SSIS searches for the files from the project's folder.
Well, today my colleague tried to run a package and he got a curious error message saying that the file could not be found under the "C:\windows\system32" folder. There's no configuration that would point SSIS to that folder and with me and a third colleague it's working well.
After some investigation we discovered that the problem has nothing to do with the user itself, but with how the user opens the project. Since the beginning I've been opening the project by double clicking the ".dtproj" file. My colleague first opens the SSIS development interface then opens the project file from the menu.
Has anyone noticed that behavior? What could be the cause for that?
error message print
Microsoft Visual Studio 2008
Version 9.0.30729.4462 QFE
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: IDE Standard
This happens because the different ways of launching the IDE end up with different current directories for the IDE process. You can test this by creating a package with only a Script Task, with the one line:
MessageBox.Show(Environment.CurrentDirectory);
And then running this project after launching it both ways.
Double-clicking the project or solution file sets the folder containing that file as the current directory. (I assume this is standard Windows process launching behaviour when starting a process based on the file extension association.) SSIS packages then look in the current directory when the path to the configuration file is relative.
We use relative paths to configuration files all the time to simplify deployment, and have to always remember to open the solutions by double-clicking the SLN file.
I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).
I am using SSIS BIDS 2008 R2. In my solution I have a Parent.dtsx package and there are a few child packages that the Parent package calls. The thing is that some of the Data Flow tasks in my packages (child or Parent) use some csv files that are kept in a folder hierarchy of the packages.
Now I want to distribute my package so I have to deploy it. I have the following quesions -
How to make the my csv files part of the deployment.
All my File Connection Managers have absolute paths. How do I convert them to relative paths? Because this will be an important concern when other consumers try to run the package.
One of the OLE DB connection strings needs to be dynamic. I mean it has to be supplied at runtime when someone will try to run the package using dtexec.
Any help/suggestions/link to resources is greatly appreciated!!
Thanks a bunch
How to make the my csv files part of the deployment.
In the Solution Explorer you'll see there's a folder labelled "Miscellaneous". To add a file to here you need to go to the uppermost node and: Right-click > Add > Existing Item...
All my File Connection Managers have absolute paths. How do I convert them to relative paths? Because this will be an important concern when other consumers try to run the package.
One of the OLE DB connection strings needs to be dynamic. I mean it has to be supplied at runtime when someone will try to run the package using dtexec.
Both of these problems can be resolved by adding a configuration file to your SSIS package.
Open a SSIS package and you'll find the option on the file menu under: SSIS > Package Configurations
You'll be able to modify almost any property of your objects within the package.
I've configured my SSIS configuration to load from an XML file. When I run the package with dtexec, I specify a different configuration file for each country I'm processing. In Visual Studio I specified this as France.dtsConfig (I have to choose one and this was the first one).
When I run the package with dtexec /FILE Import.dtsx /Reporting V /ConfigFile "C:\Italy.dtsConfig" I still see the output telling me that "The package is attempting to configure from the XML file France.dtsConfig".
I thought I could override the configuration by providing a different dtsConfig file for each country. Is this possible? What am I doing wrong?
I am using SQL Server 2008 R2 and I was getting the same issue with the Configuration override apparently being ignored. I found the trick I needed was to remove the XML config setting from the package (Package Configurations), and then when running the package the XML configuration file you specify is applied. There is however no message emitted about using the file (and since you removed the XML configuration definition from the package, that message is also not emitted).
MSDN has an explanation (go to section "Understanding How SSIS Package Configurations Are Applied at Run Time") that at first didn't make sense to me, but after finding that not having an XML configuration file defined gives the desired result, I can see what it is trying to say.
In my case I was using the XML file to set the instance name of the server on which the [SSIS Configurations] table was found. At design time this was DEVServer in the connection manager object, and I want to override the value to TESTSvr. Following the rules:
"The utility applies the configurations that were specified in the package at design time and in the order that is specified in the package." So the value DEVServer is loaded from the package.
"The utility then applies any options that you specified on the command line." The value in my XML file (TESTSvr) is now loaded. I can supply any filename I like here, and it will be loaded (be it France or Italy).
"The utility then reloads the configurations that were specified in the package at design time and in the order specified in the package. ... The utility uses any command-line options that were specified to reload the configurations." Note the second part of the rule, about using the command line values. Since we currently have set the server to TESTSvr, this value is now used to load the other configuration values from the [SSIS Configurations] table that you want.
I don't have a reference to an article that documents this behaviour, but I have confirmed it. If the file specified as the configuration file in the package configurations is available at run time, it will be used in preference to the one specified on the command line.
In my experience and my opinion, this is contrary to normal behaviour where specifying something in a command should override the built-in default.
To use the configuration file specified in the dtexec command, rename or delete the file that is specified in the Configuration String of the XML configuration file in the Package Configurations Organiser.
Found a way!
In the designer simply uncheck the "Enable package configurations" option under SSIS -> Package Configurations, and save.
dtexec will still honour the supplied configuration file on the /conf switch, but it will no longer attempt to use the design time configuration file even if is accessible.
I still agree that this is strange behaviour, and that the /conf should override design time settings no matter what.
This should work
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Specify the complete config file location within double quotes
Edit :
When you have deployed your package in MSDB then the command to execute the package is
DTEXEC /SQL "\Package.dtsx" /SERVER "Server Name"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Else if you have deployed in File System then
DTEXEC /f "Physical Package Location"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Check whether you are pointing to the correct package
MSDN
You can use the /ConfigFile option to load additional configurations
at run time that you did not specify at design time. However, you cannot
use the /ConfigFile option to replace configured values that you also
specified at design time