At 12:50 AM 2/12/2005 +0000, you wrote:

>Before logging on, if a user triggers an action in the GUI that causes
>my application to try and open a query the error message I am getting
>is (approx.) "Your user name and password are not defined etc. etc.".
>
>What I would expect (and want) is "You have not logged in".
>
>On a related issue, once having logged in and then out again, a
>similar action makes IBObjects re-connect silently with the prior
>User/Name password. Obviously not what I want (for security reasons at
>least).
>
>Am I missing some obvious property value in IB_Connection?

Yes. Several.

First of all, look at the PasswordStorage property. There you have four
levels of security re storage, from psNotSecure (user name and password are
stored in the DFM and so are compiled in the app) to psNone, where the user
name *may* be stored but the password must be entered for every login.

What you get as default depends on whether you are using a TIB_Connection
component directly or indirectly (through a TIBODatabase). The
ib_connection default is psNone, while ibodatabase overrides it to
psNotSecure, to be consistent with the VCL.

Second, I think you'll find the problem with the login credentials
surviving the disconnect is down to stray values being stored in
Params. Simply, *don't* use the Params property for storing things that
you need to be volatile. Use the ib_connection properties directly, clear
the params and keep them permanently clear. Just a warning here, though,
the IBOAdmin components sometimes seem to transfer the connection
attributes to Params whether you want it or not. If you are using any
service components, keep an eye open for this: you might need to clear
Params in your AfterDisconnect event.

On the subject of exception message interpretation, IBO delivers the
messages that come from the database. Of course "Your user name and
password are not defined.." is the server's text for exception code
335544472 (gdscode login) meaning that the login attempt failed
authentication. It's up to you to catch that exception and deliver a
friendlier message to the user. The most convenient way to do this is to
define all your user-friendly message strings in a separate unit and just
have your exception handler grab the relevant message to pass in place of
the one from the engine. You could also use resourcestrings...

./heLen