Subject | Lock conflict on no wait transaction |
---|---|
Author | Dan Taylor |
Post date | 2004-10-14T10:50:34Z |
Hi,
We currently have a problem altering the database structure in our
firebird databases. We're running Firebird 1.5 classic on a Redhat
Enterprise 3 server.
More specifically, the problem occurs when attempting to add foreign
key constraints to a table - even when the table has just been created
- the server complains that the table is in use. In the past we've
dealt with the problem by shutting down all database clients and
performing the task with only the SYSDBA user logged in, but yesterday
we found ourselves in a situation where we were not able to do this.
This *may* have been due to some client remaining logged in, but due
to an apparent shortcoming in the server we were unable to confirm (or
disprove) this.
The database we're administering is critical to our business and is in
constant use by around 10 clients, so shutting it down is not
something we're keen to do. Ideally we'd like a solution which allows
us to add and edit new tables while other clients are using other
parts of the database. Failing that, is there any way that we can get
the database into a state where we can be sure that only one user is
logged in, so that we can make changes?
Dan
--
Dan Taylor
Software Development Engineer, JTL Systems Ltd
PhD Student, Reading University, UK
http://www.logicalgenetics.com
We currently have a problem altering the database structure in our
firebird databases. We're running Firebird 1.5 classic on a Redhat
Enterprise 3 server.
More specifically, the problem occurs when attempting to add foreign
key constraints to a table - even when the table has just been created
- the server complains that the table is in use. In the past we've
dealt with the problem by shutting down all database clients and
performing the task with only the SYSDBA user logged in, but yesterday
we found ourselves in a situation where we were not able to do this.
This *may* have been due to some client remaining logged in, but due
to an apparent shortcoming in the server we were unable to confirm (or
disprove) this.
The database we're administering is critical to our business and is in
constant use by around 10 clients, so shutting it down is not
something we're keen to do. Ideally we'd like a solution which allows
us to add and edit new tables while other clients are using other
parts of the database. Failing that, is there any way that we can get
the database into a state where we can be sure that only one user is
logged in, so that we can make changes?
Dan
--
Dan Taylor
Software Development Engineer, JTL Systems Ltd
PhD Student, Reading University, UK
http://www.logicalgenetics.com