--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
tests and see what I can find.
> At 09:31 PM 16/12/2004 +0000, you wrote:you are
> > >
> > > So - if you're able to connect then you are on Superserver and
> > > probably looking at a "homing" problem: the server doesn't knowneed
> >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 separatelywhere
> they are different.server will
> Essentially (except for embedded, which is a bit different) the
> 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 somein the
> 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
> filesystem, it next looks at the FIREBIRD environment variable. Onsome
> windows installations, I've noticed that the installer doesn't installanother, it
> it. If you have file-copied the structures from one server to
> definitely won't be there. You have to be careful to install it ina level
> where the envvars are visible to the OS user that owns the Firebirdservice.
> 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.directory, it
> As a last resort, if the server still hasn't found its root
> tries to read the RootDirectory parameter in firebird.conf. Ifthat's not
> set, or it's set to a root that doesn't contain security.fdb, thenAPI call
> 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
> intercepts the user and refuses the connection if the user isn't SYSDBA.it's very
> 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,
> easy to overlook the fact that IBO out-of-the-box doesn't know about aYou must
> client named fbclient.dll located in the Firebird bin directory.
> copy fbclient.dll into the system directory and rename it to gds32.dllthrough
> 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/Superserverincompatibility
> 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 goodidea in a
> multi-user environment (and it's NOT!). Keep cpLocal for embedded and,Do all
> otherwise, only for ad hoc hits on the database during development.
> your testing and deployment with TCP/IP.Thank you very much for all the great information. I'll run a few
tests and see what I can find.