At 05:58 PM 2/12/2005 +0000, you wrote:

>Helen,
>
>One of my questions was not clear enough. Even I only just realized it<s>.
>=== your response ====
>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.
>=======================
>
>What I was actually trying to address is getting this message after a
>call to IBOQuery.Open when the user is not logged in. Rather than
>automatically trying to connect and getting the (reasonable) reply
>from the server, I would like like IBObjects to return a "Not logged
>in" message.
>Is there a setting for that or do I have to check myself in every
>situation?

Something that's possibly happening here is *not* desirable and is legacy
VCL behaviour that occurs when you manually set the DatabasePath property
of a TDataset descendant. If you put a hard databasepath directly in a
TDataset, it actually tries to create is own connection to the
database. Of course, this connection *won't* be the one that you have
carefully configured, it will be a bare-bones one with all the defaults and
a different transaction handle to the one that's associated with your
ib_connection as the default transaction. This is not a model for
well-controlled data access! Really it's there because the TDataset is
able to connect to data sources that are not databases, viz. text files and
spreadsheets, etc., that are not database tables, don't work in transaction
contexts, etc. etc.

In the IDE, zap out the DatabasePath property entirely (on all your
ibodatasets) and use *only* the ib_connection property. That's just
standard advice...not the answer to your question (at least, not directly...)

Now, if in fact you have already done that form of cleanup, then go to your
ib_connection and replace its DatabaseName property with some friendly name
that is not a databasepath. It can be anything you like. Make sure that
your Server, Path and Protocol properties are properly set. That way you
can be certain that every time a connection is made, it will be through the
ib_connection that you configured.

On the subject of avoiding the standard message, nothing is different to
what I advised you before. You should always intercept exceptions that you
want special behaviour for. A message different to the standard message
returned through the API is special behaviour.

As for hacks -- checking for MyConnection.Connected isn't necessarily going
to give you the answer you need, since the Connected property only becomes
false if it is explicitly set false by your application. In other words,
an uncontrolled breakage of the connection does *not* magically set
Connected to False. On the other side of the coin, you shouldn't be
writing applications that arbitrarily set Connected to False while the
connection is in a state where it's not ready to detach. Then you end up
with the application thinking there is no connection, while the connection
is still open and datasets are busy cleaning themselves up, waiting for
cursors to finish fetching, waiting for some other request to complete,
etc. etc.

Now, going back, fix up any confused property settings that you have, so
that you totally rule out the possibility that your datasets are going to
try and make their own connections to the database. Write handlers for
error code 335544472 that displays your own message and sets off your own
action, whatever you want to happen under those conditions that is
different to the default behaviour.

Helen