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