> No, I don't have any code in the BeforeDisconnect event.
> Below is the callstack just after the access violation.

Thanks, I can see where the characteristics call is coming
from - its obvious when you know when to look.

In your copy of IBO, in the IBA_Statement.IMP unit,
TIB_Statement.SysDeallocate method can you see the following
lines?

if Assigned( IB_Connection ) then
//!!! Check for a lost connection.
FSQLDialect := IB_Connection.SQLDialect;

I am trying to work out whether the call to SQLDialect is
in response to the comment (a way of seeing if the connection
still exists) or whether the comment is indicating that there
needs to be an additional check to see if the connection
has been lost. (And I hate to say it, the comment looks an
awful lot like one of mine :-)

The reason for wondering is, I cannot think of any reason why
there should be a call to get the dialect at this point in
the processing - unless it is a way to force a check whether
the connection is still working.

I just did a search of the archives and found this comment
in from Jason in January (in regard to connection recovery):

"You are not doing anything wrong. This capability is near the
top of my list for features to complete. Most of the work for
this is in place. I just need to focus on it and get it done."

So I am not sure that what you want to achieve is actually
supported at this time. However you could try modifying the
lines so that:

if Assigned( IB_Connection ) and
not IB_Connection.ConnectionWasLost then
FSQLDialect := IB_Connection.SQLDialect;

This should solve the immediate problem, but I cant guarantee
that you wont find others ;-)

--
Geoff Worboys
Telesis Computing