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

> At 09:31 PM 16/12/2004 +0000, you wrote:
>
> > >
> > > So - if you're able to connect then you are on Superserver and

you are

> > > probably looking at a "homing" problem: the server doesn't know
> >where its
> > > root directory is. That's easily fixable.
> > >
> > > Helen
> >
> >I double checked and one of the problems is on a Classic server. Keep
> >in mind, that the only problem is with AlterUser. Also, the exact same
> >code worked with earlier versions of Firebird.
>
> Doesn't signify. Firebird 1.5 changes a lot of things
> architecturally. It's different software.
>
>
> >How do I fix a "homing" problem? I have your book, is it in there?
>
> In a way, yes, but it's not identified as "how to fix a homing problem"
> ! It does emphasise that, if you're doing manual installations, you

need

> to understand how the Firebird server goes looking for its stuff.

And you

> will see that Firebird 1.0 and Firebird 1.5 are treated separately

where

> they are different.
>
> Essentially (except for embedded, which is a bit different) the

server will

> look first in the "root" above where the server executable is.

There it

> expects to find security.fdb, firebird.log, firebird.conf,

aliases.conf and

> firebird.msg. In its own directory, Classic also expects to find some
> other stuff...IOW, if you break the installed structure, or "upgrade" a
> server by copying new stuff over old stuff, you'd better know how (and
> *whether*) you can configure it to fix it.
>
> OK, if the server can't determine its root from its current position

in the

> filesystem, it next looks at the FIREBIRD environment variable. On

some

> windows installations, I've noticed that the installer doesn't install
> it. If you have file-copied the structures from one server to

another, it

> definitely won't be there. You have to be careful to install it in

a level

> where the envvars are visible to the OS user that owns the Firebird

service.

>
> If the envvar isn't set, the next place it looks is in the
> Registry. Again, if you copied rather than installed from machine to
> machine, this will be missing. You need to run the instreg program

from

> the bin directory beneath where the Firebird root stuff is.
>
> As a last resort, if the server still hasn't found its root

directory, it

> tries to read the RootDirectory parameter in firebird.conf. If

that's not

> set, or it's set to a root that doesn't contain security.fdb, then
> obviously it won't be able to connect to it.
>
> Also ensure that, when the application tries to invoke AlterUser, it is
> logged in as SYSDBA. A non-SYSDBA user has only SELECT privs in
> security.fdb. It's likely (though I don't know for sure) that the

API call

> intercepts the user and refuses the connection if the user isn't SYSDBA.
>
> The other thing you have to be sure of, of course, is that the correct
> client library is loaded. If you did a machine-to-machine copy,

it's very

> easy to overlook the fact that IBO out-of-the-box doesn't know about a
> client named fbclient.dll located in the Firebird bin directory.

You must

> copy fbclient.dll into the system directory and rename it to gds32.dll
> unless you've modified IBO to load fbclient.dll from its home.
>
> Follow Luc's advice and make ALL of your local applications connect

through

> localhost; otherwise you are building Classic/Superserver

incompatibility

> into your application code. In any case, just because you *can*

connect a

> user app through the IPServer (cpLocal) does not mean it's a good

idea in a

> multi-user environment (and it's NOT!). Keep cpLocal for embedded and,
> otherwise, only for ad hoc hits on the database during development.

Do all

> your testing and deployment with TCP/IP.
>
> Helen

Thank you very much for all the great information. I'll run a few
tests and see what I can find.