Full Table Lock

[Chris Schippers]

Can someone explain me how it is possible to get an full table lock in progress?

The fact is, I get error 6527 when Progress wants to write a newly created record to the database.
But by the time we can check with promon if we can find the user who is causing the problem, the record lock is already gone.

Message info:
Table < table name > is locked. Record create failed. (328) (6527)

Some other user has the whole table locked. The database manager cannot get a record lock for the newly created record. Thus the create operation fails.


:blue:

 

[MurrayH]

Under V9 a "tablemove" will do a table lock and I think you can do it through SQL-92 too. You may also be able to do it by playing with the _lock or _file tables (??)

Murray

 

[Chris Schippers]

Thanks for the reply.

The problem is that we don't use table move or sq92 in our application.
We migrated our pilot client recently to v9.1b and ever since he had this problem twice.

There are no other possibilities to get a full table-lock?

Because it only happened twice in a month it is almost impossible to reproduce it.

 

[mra]

Maybe you can set promon to repeat displaying the lock table, and then spool it to at file
- This worked for us.

Regards
Mike

 

[Chris Schippers]

I found it. ;p

As mentioned before there are 2 options to get a table lock: (at least that I know of)

1. PROUTIL TABLEMOVE
2. SQL-92

Both of the options our client did not use.
What he did use was ODBC.
ODBC also uses SQL-92.

There are a few options how you can configure ODBC.
In the driver setup you can choose the default Isolation Level.
Read Uncommitted should be read-only
Read Committed should be read-write
Repeatable Read should generate a table lock.
Serializable (I have no idea)

Our client used for a short period of the the repeatable read, so that's why we could never find the lock.

Problem solved.

Thanks a lot for the replies!!
:biggrin: :biggrin: :biggrin:

Chris.