Fix Relative Paths

This feature is helpful in setting up packages to use relative paths in connection managers and in the path to dtsConfig files. It was mainly coded to workaround this bug in SQL2008, but it can also be helpful in SQL2005.

For more information about using relative paths in SSIS, see this blog post.

This feature adds a "Fix All Relative Paths" button to the Package Configurations dialog:

FixRelativePathsPackageConfigurationDialog.png

Clicking that button will change full paths (i.e. "c:\Directory\test.dtsConfig") to relative paths (i.e. "test.dtsConfig") if the following are true:
  • If the working directory for the current Visual Studio process is the same directory as the current package.
  • If the package configuration is an XML file and the dtsConfig file is in that same directory.

This feature can also be run on multiple packages simultaneously by using the right-click menu item on the project node in Solution Explorer:
FixRelativePathsMenu.png

When selected, BIDS Helper will scan all open packages. Inside each package, it will scan all XML file package configurations and all connection managers looking for full paths which point to a file in the same directory as the package. The restriction mentioned above about the working directory for Visual Studio still applies.

The results of this command can be seen in the Output Window:
FixRelativePathsOutputWindow.png

Last edited Jan 28, 2009 at 8:42 PM by furmangg, version 5

Comments

nicolasdiogo Jun 27, 2012 at 9:47 AM 
Hi Roelf,

you can always use an environment variable on the server running the package to be your 'base' location and everything else can be relative to this location.

regards,

Nicolas
www.BrainPowered.net

Roelf Aug 8, 2011 at 7:12 AM 
It's quite hard to make sure that the working directory of the process that opens/executes the package is the same as the package.
Packages can be executed from SQL Agent, Management Studio, Visual Studio, batch file, powershell script, and in SQL Server Denali from TSQL. The burden of making sure the working directory is correct would be too great for me to use this kind of configuration.

What would really be helpful is a relative path which is not dependant on the working directory of the process, but a relative path from the package location.
Or just wait for SQL Server Denali's new configuration features for SSIS packages... :)