Hi,

At April 28, 2004, 05:53, Martijn Tonies wrote:

> Hi,

>> Thanks once again for your reply. I'm still unable to understand the
>> rational behind the behavior. Let me try with the direct firebird
>> ("paid") support and see if I can gather more details in this regard.

> It was some kind of design decision. It undoubtely has to do
> with multi-versioning and concurrency etc etc of records. And
> therefor, simply: safety reasons.

Here's what I found by doing a search in the Firebird Lists on IB
Phoenix:

From Claudio, 14-mar-2002:

"Object in use is different than exclusive access to db is need or secondary
attachments cannot validate db.
Object in use means that in the same session, you did a select (probably an
update, delete, insert as the same effect) on a table or procedure that's
going to be altered. There are two solutions:
- You do a hard, explicit COMMIT. Autocommit and commit retaining don't
work. Most of the time a hard commit works.
- You play safe and detach. If there's no other attachment, this action
ensures the engine itself unloads the db from memory and frees the file
handles associated with it. Next time you connect, your metadata change
should succeed immediately."

From Ann, 20-Dec-2001:

"The two errors["unsuccesfule metadata update" and "object in use"]
you're seeing are really the same - object in use is a secondary error
that clarifies the more general "unsuccessful metadata update". The
error arises when some connection has an "interest" lock on the object
in question. "Interest" locks don't interfere with reading or writing
instance of the object, but prevent deletion or modification of the
object itself. A prepared request gets "interest" locks on the tables
and indexes it uses."


I know some improvements are supposed to be made for FB 2.0 and some
has been made in FB 1.5. And, I think the only way for this type of
error to be totally eliminated might require that the DDL statement
execution be deferred to a later time when the objects that it
requires are no longer in use. And, this could mean that if the
object(that the DDL statement needs) be in use for 72 hours, as an
example, the DDL statement wouldn't be executed before then. Also, I
think this could(and most likely would) generate support questions as
to why the changes are not made immediately after the DDL statement
was sent to the server.

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)