--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 11:47 PM 31/01/2005 +0000, you wrote:
>
>
>
> >I have Firbird 1.5.2 installed on a Windows 2003 server running as

a

> >service. The service applet shows that firebird is running and the
> >firebird log file doesn't show any errors. However, if I just
> >type "gsec" on a command line I get:
> >
> >unavailable database
> >unable to open database
> >
> >However, if I run Firebird as an application, everything works

fine.

> >Unfortunately, I'm using it as the back end of a web app so I can't
> >count on a particular user being logged in all the time -- nor

would

> >I want to.
>
> Of course not. So you need to find out why gsec's request can't

find the

> security database - which is what your problem reflects.
>
> The first thing I would want to be assured about is that you don't

have

> another database service running, that is what your application

code is

> actually connecting to, e.g. fbserver.exe is running from one

installation

> (and the application connects to that when you run it as an

application)

> whereas you have a later installation (that might be Classic) that

gsec is

> trying to connect to, but can't, because the fbserver application

process

> is using the gds_db port.

Hmmm. It appears that when switching back and forth between
application and service, I have gotten myself into a position where
fbserver.exe is being started once as a service, and then again as an
application when I log in. I don't think that this is the root of the
problem though.

It looks like I'm going to have to manually remove the automatic
application startup fbserver.exe when I log in. Any idea how I go
about that?

> If you find that fb_inet_server.exe is in the same bin dir as where

you are

> trying to run gsec from, then there's your problem.
>
> You see, gsec will try to connect to the server in the bin

directory where

> the gsec executable is located. It doesn't need an available

client

> library, since it makes its own internal discourse with the API.
>
> NB also that you have to provide the -user and -password switches

to your

> gsec command. You might have been able to do without them on

another

> machine where the ISC_USER and ISC_PASSWORD environment variables

were

> available (not a sensible idea on a production machine!!).
>

I usually run gsec with a complete command line. However, when I do
that on a server that's working, it tells me that my username and
password are invalid. I get the same results here if I give a
complete command line or just type gsec.

> And also note that *any* local connection to Classic on Windows

must be

> through localhost, and the command must include the -database

switch (plus

> the "localhost:c:\Program Files\firebird\firebird_1_5

\security.fdb". You

> can omit the double quotes if there are no spaces in the path to
> security.fdb...)

Now that's interesting. I shut down the second application version of
fbserver that was running -- described above -- but that didn't fix
my problem. However, when I run gsec with the "-database" switch you
describe, it works! I'm definitely running superserver though. I can
also telnet into port 3050 so I know that it's listening.

Anyway, if I can get rid of the second application version of
fbserver.exe to stop running when I log in, I can use the -database
switch to work around my problem. Strange though.

>
>
> >I suspect that it's a permissions thing, but I have tried granting
> >all kinds of permissions to the firebird install directory and I
> >always get the same thing.
>
> I doubt this is the problem, unless you have done something weird

with

> permissions. On Windows the service is owned by the LocalSystem

user,

> which has stronger powers than even Administrator.
>
> ./heLen