I would say this is a bug in driver. There is an open connection to
the database if commit() or rollback() fails. See my previous post.

Roman

--- In Firebird-Java@y..., Nickolay Samofatov <skidder@b...> wrote:
> Hello, Stephan !
>
> Thursday, November 21, 2002, 6:10:10 PM, you wrote:
>
> > I was surprised to read in your reply to Phil about the high
> > severity of the well-known "OBJECT IN USE" bug. We have databases
of
> > the mentioned complexity of several hundreds of database objects.
On
> > nearly every release of our application we have to make some
changes
> > to the data schema and the problem arises very often. As a
> > workaround since almost three years we just close the connection
> > (the file gets closed) and we resubmit the last sql statement
> > through the newly opened connection. From your mail it seems not
to
> > be enough and we are in risk to corrupt the databases. Should we
> > change our strategy?
>
> Maybe. After dropping of index some internal structures may still
point
> to the page where it was. If you try to update or insert some data
to
> this table you will very likely get a message that database is
> corrupted (restart will cure the problem since no actual corruption
> happened). But there is a possibility under some usage scenarios
that
> type of page that old index points to will be index page. Database
> corruption is possible in this case. In general, chances for real
> corruption are very slight (much less then from bugs in GC
routines).
> Reported corruption happens relatively often, but actual corruption
> really rarely.
>
> Closing all SS connections may not cure a problem completely,
> because metadata caches may not get deleted when you close all
> connections. Closing all CS connections is equivalent to server
> restart. Backup/restore is recommended mainly because of GC bugs
> that sometimes arise during complex metadata operations.
> But performing complex metadata operation in one step was nearly
> impossible before FB1.5 because of "OBJECT IN USE" problem
> so this problem also appears rarely.
>
> I would recommend backup+check for restorablity of backup before and
> after metadata alteration anyway.
>
> --
> Best regards,
> Nickolay Samofatov mailto:skidder@b...