Dear Daniel,

Thanks for your reply.. I hope I'm understanding the
background of the "restriction".. (although I'm not in
complete agreement of the behavior).

> the DDL statement
> execution be deferred to a later time when the

I wish this could be done but my observation
contradicts this solution. Just having two connections
and performing create table with a foreign key
definition gives me the error. So, such a 'defer' DDL
approach will not work. One solution I can think of is
to create the tables up front rather than doing it
from my application. This way, I can ensure
"Exclusive" access to the DB (at least from my own
application) during the DDL execution. I can not still
avoid some user trying to connect using (say) a isql
console to the same DB !

Thanks,
Suresh.K.V.

--- Daniel Rail <daniel@...> wrote: > 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)
>
>

____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html