At 14:26 1/10/2008, you wrote:

>Helen
>
>I have been running firebird classic 1.5 with read only root file
>systems for some years by symlinking the security database and setting
>the environment variables to writeable directories. This has always
>worked flawlessly.

It seems that there you have been using libfbembed.so w. direct connect to database *file*

>The difference now is that I need to access
>databases (which are all located in read write directories) by using a
>url and not just local paths. This is because although previously only
>one application accessed the data now two (or more) processes need to.

Right, so you need to activate fb_inet_server, which will require xinetd to be up-and-running (and of course the firebird script present and correct there).

>So for example if I use isql to connect with
>
>connect /var/mydata/adatabase.fdb;
>
>all works fine
>
>but if I use
>
>connect localhost:/var/mydata/adatabase.fdb;
>
>it doesn't.

As a rule of thumb, you'll need your POSIX applications to use libfbclient.so. In latter years, Alex has distributed both clients in the Classic packages. Check in your bin directory whether you have it. You'll need to symlink it so your apps find it rather than libfbembed.so.

>In the first case the isc_lock* and init file are written to the
>directory specified in FIREBIRD_LOCK but in the second the files are
>written to the firebird root folder (if the file system is set rw else
>fails). So the issue is why does firebird ignore the environment
>variable when it uses the second connection form?

Hmmm, I don't think the conclusion being made here is necessarily correct. A direct connect, i.e. one made through libfbembed.so, is exclusive. So your attempts to have multiple apps connect as network clients will fail. But more to the point I guess is that the environment variables are not available to remote clients.

>The root filesystem is set up readonly with various tmpfs mounts for
>directories that need write access - such as /var, /tmp etc. This is
>because the system is used in a machine control and it is desirable
>that the system is not modified or corrupted readily.

Fair enough...others may have some tips for you in this regard. From my POV, I'd regard any such fiddling about to be experimental. The existing situation which you've said worked flawlessly is within a very limited space: one local user with exclusive access to a database, which it is reading as a file. The new situation is client/server, where you have a full-blown server handling remote clients.

./heLen