I am using SSIS 2012 to perform a couple basic tasks. The issue I am having occurs in both a Process Execute task and a Flat File connection. When developing the file is local, but I am using an expression to replace the file directory once deployed. I have the files, which are a CSV and a BAT file in the "Miscellaneous" folder.
I would like to be able to reference the relative path of the files rather than an explicit directory on my computer. This would also prevent other developers from having to stage the files locally before being able to even validate the package.
Try using Project Parameter as your folder path.. and use it in your expression Something like
#[$Project::FileLocation] +#[User::FileName]
Related
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 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.
I have a flat file stored locally on the same server where SSIS is running.
When choosing the location of my flat file in the flat file connection manager, I could use the local drive (d:\testfiles\flatfile.txt) or I could use the UNC path (\myserver\flatfileshare\flatfile.txt.)
Both are pointing at the same file and the package is succesful either way. Is there a performance reason for why I should choose one over the other?
More than a performance reason, if you choose the UNC path, you have a more flexible solution. In that case, if you change the SSIS package, so it runs on another server, the path to the file will be correct.
Specify your files like this:
\\server\sharename\path\file.txt
This will work in both places.
Referred to as a UNC path.
When I had XP, I loved this utility for generating them - clippath. You could right-click a file and it would copy the path to your clipboard. Magical.
Now I'm on Win7 x64 and it's not supported. Windows7 has a copy file path, but it seems to use the drive letter, which is not what we want, is it?
Looking up a file is a trivial location, I wouldn't worry about the diff.
I'd use some sort of package configuration to store the path for the file, it's a much more flexible solution.
I have the need to copy the entire contents of a directory on a FTP location onto a shared networked location. FTP Task has you specify the exact file name (not a directory) and File System Task does not allow accessing a FTP location.
EDIT: I ended up writing a script task.
Nothing like reviving a really old thread... but there is a solution to this.
To copy the all files from a directory then specify your remote path to be /[directory name]/*
Or for just files and not directories /[directory name]/.
Or specific file types; /[directory name]/*.csv
I've had some similar issues with the FTP task before. In my case, the file names changed based on the date and some other criteria. I ended up using a Script Task to perform the FTP operation.
It looks like this is what you ended up doing as well. I'd be curious if anyone else can come up with a better way to use the FTP task. It's nice to have...but VERY limited.
When I need to do this sort of thing I use a batch file to call FTP on the command line and use the mget command. Then I call the batch from the DTS/DTSX package.