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@...