At 10:11 AM 25/08/2005 +0000, you wrote:

>The first thing I triead was the firebird-net list, but they referred
>me to this group...

However, according to you, in your repost to THIS list:

>It turns out that the '/windows/system32/inetsrv' directory is the
>*current* directory when ASP.NET loads the .NET provider dll
>(FirebirdSql.Data.Firebird.dll). So it seems that the firebird.conf
>file is loaded from the current directory rather than from the
>directory containing fbembed.dll.

If this is so, then it is contrary to the built-in geography of the FbEmbed
elements - read the relevant section in the Firebird 1.5 release notes if
you are not clear about this.

>Also, I think that it is fbembed.dll that should determine its own
>location and setup udf paths accordingly. I do not think that the .Net
>provider has anything to do with that.

Yet your statement above indicates that you think that it does. If it *IS*
the case, then it is contrary to what happens with other interfaces. Only
the .Net provider developer can put you straight about the bizarre nuances
of *that* particular interface.

As to the dll setting up its own paths, etc., how could it do that? It
does expect to find firebird.conf, firebird.msg and aliases.conf in its own
directory and it will write firebird.log there. If you unzipped the
download kit directly into your application directory, with the option to
keep paths intact, everything would be in the right place.

Unless the .NET provider has its own way of doing things...hence the advice
to ask about this on the firebird-net-provider list, rather than here. If
it *is* different, those are the folk who can tell you *how* it is different.

./heLen