This content has been marked as final. Show 8 replies
Have you tried
Documentation says:A value of NONE can be used if lock_mode is set to VE (version-exclusive). This causes rows locked by any workspace to be unlocked.Also: when you tried to unlock, was everybody else logged out an were there no more sessions active?
If the where_clause parameter is not specified, all rows in table_name are made accessible.
rcx4009v2 wrote:24/7? Wow. What kind of users are those?
Some users are connected 24/7 to the db.
Anyway, I would think that if a user is still connected, and has not merged some of their changes, that the rows would be locked no matter how hard you try to unlock them.
But which kind of locks are still left? Have you checked that? Maybe the VE-lock_mode is not the correct one.
To be able to unlock rows that have been locked by a different user, the user currently needs to have WM_ADMIN_ROLE (or be the SYS user). The other users do not have to be logged out, but the rows cannot have been locked in a uncommitted transaction, otherwise the rows will not be able to be queried by the other session.
Thanks for the response. I tried your suggestion regarding using a user with WM_ADMIN_ROLE privilege, but I still have no luck with regards to unlocking of rows in my LIVE workspace.
I can only unlock the rows when I execute DBMS_WM.UnlockRows using the Lock owner account.
The problem is that there are too many users in the Database and it is not right that i'll have each one of them unlock rows locked by their user everytime a lock occurs.