Hi Elmar,

thanks for your answer.

> "modified" Paswods for SYSDBA are the usual case - you should never
> expect your client to have "masterkey" there.

Yes of course but in my case some of the other applications automatically
change the sysdba-password and my customers don't know that changed
password! So nobody at the customers side knows the password and I can't add
my user/password or even login!

> ... - mayby your application should refuse to work on other
> Versions. Your application should have the ability to connect to
> DB-Server listening on an different port. This does enable installing
> an additional instance if required.

But if I refuse it, what's next? They'll call me and i have to solve the
problem. As the different versions of Firebird are not compatible with their
prior versions I can not tell them "Use my Firebird Version (1.5) and
everything will be ok". If the other app uses Interbase they can run into
the changed behavior regarding "ambigious references"...

> ...
> You can have an server running on the workstation.

Yes, of course, but that's exactly my problem. Other applications also use
their own firebird/interbase version.
For example: If they install Superserver Version 1.0[3] after my 1.5
(clientsetup) the Setup don't overwrite the system32/gds32.dll because it's
newer. But the firebird.msg will be overwritten and so doesn't match the
DLL.
At the moment I don't use any 1.5-features - I'm (my app - of cource) still
Interbase 6.0 compatible but in future releases I would like to use some of
the V1.5 (V2.0) features.

> In most cases this can be prevented by using the renamed DLL - the
> registry-items should be superflous.

"should be"? What about the firebird.msg-file? Is it needed?


With regards
Thomas