Subject Re: AlterUser????
Author johnnorthrup34
--- In, 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
> 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
> 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
> 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
> 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
> 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
> localhost; otherwise you are building Classic/Superserver
> 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.