Hi Helen, Adam, Lester,

> HTTP protocol is stateless. The database's API certainly isn't.

Yes, which creates other complications, I know...

> On the Firebird side, you are talking about two totally different
> things. One one hand, inability to *get* a connection, while, on the
> other, some way to decide that the connection you have got is too slow.

Yeah, well, slow, that is the visible symptom. I guess quality of
transport has gone down as well. Not sure how many corrupted packets
were refused.

> If you can't *get* a connection, you are waiting for the NOS to timeout
> your request. If you connected to the database, started a transaction and
> submitted a request, then there is no way to stop that running transaction.

I understand. By killing the client the transaction will remain,
"limbo", if I recall correct.

> IBO does have ways to abort a request (study the helpfile). So it's
> possible to define your own request_too_slow exception and call on the
> session timer to monitor the time it takes to satisfy a Fetch or some other
> request; write a handler for the exception that sets off the graceful
> unwinding back through request-transaction-connection.

Allthough off-topic that seems the way to go... tnx!

> However, the API itself has no way to know that the request is taking too
> long; nor does it have any way to know if the network connection has been
> broken. So, in IBO, the Connected property remains true. The first the
> app will know that the connection is gone is when it submits *another*
> request and gets an exception.

Thank you all, got some idea now!

John