I have a package collection with one parent package that calls several child
packages that share a common configuration file referred to using a relative
path (everything is in the same folder).

If I put the child packages and config file in a different folder execute
the parent package, the child packages fail to find the config file. If I put
the config file with the parent package, the child packages find it.

With an asp.net site - the child packages don't find the config file in
either their own or the parent package folder.

This has led me to believe that the location where the "executable" is
launched dictates where the config file needs to be. On this basis I have
tried putting it in the following (increasingly desperate) locations:

virtual dir root
virtual dir bin
site root
drive root
\Program Files\SQL Server\90\Binn (location of MsDtsSrvr.exe)
\Windows\System (location of W3SVC)
the "My Documents" directory of the app pool identity

One exception is that the config file is found if the app pool identity is
an administrator of the SQL Server box - but this is not an acceptable
solution. However at the rate I'm removing security in my search for a
working setup, it won't be long before everyone's an administrator anyway!

Can anyone give me any guidance?

Ta in advance,
David

Found it!!!!! Desperation wins through!!!

\Windows\system\inetsrv (app pool location)

But it's not going to be a very well structured package environment. And I
don't know if I can different locations for test and live will be possible.

All in all, fairly ridiculous if you ask me.

"David Norman" wrote:

Config files for child packages called from asp.net will also be found during
execution relative to this directory:

\Documents and Settings\App Pool Identity User\

So to have two separate package collections on the same server e.g. for test
and live, you need two sites using different app pools with different
identities. Otherwise both collections will use the same config files.

I think the way to structure this so you still have the flexibility to run
the packages both directly and via the site is to put copies of the config
files in the app pool home dir. The downside is you can get out of sync and
access to the directory needs to be opened up to more people.

But I won't add my voice to the chorus of SSIS bloggers who trumpet the need
to follow disciplined practices - template packages, carefully designed
folder structures, etc. These are just workarounds for a not very easy to use
environment.

One thing I believe IS good practice is to not edit live packages directly.
If you're happy to hack away at the config file paths in live .dtsx files
then you can you ignore these posts entirely.

Hope this helps somebody, it's taken me a long time to figure all this out.
David

"David Norman" wrote:

Sorry, this information is not correct. I was viewing logs that excluded
OnWarning messages.

As far as I am currently aware, the only guaranteed place to put
configuration files where they will be found by an asp.net site using an app
pool identity other than Admnistrator is in \windows\system32\inetsrv

"David Norman" wrote: