We have a bug with OWB in v14.1 which doesn't release project locks when closing.
Does somebody knows the SQL request to purge project locks, the same way we may do with the security.locks page?
The "import export lock" on the security.locks page is the "open in OWB" lock.
(but of course using that page is "unsupported")
Can you refer to the bug number you are referring to, so that I can take a look and confirm.
00082236: OWB regression on project lock
Clarity PPM Services Architect
Mobile: + 33 6 19 51 88 68
The bug CLRT-77661 linked to the case is in review with development team. From the bug it looks like the lock on sub project remains. The best way to unlock is to do via security.locks page as Dave mentioned.
The table being queried by security.locks is prlock where prrecordid is inv_investments.id, deleting this record would unlock the investment (tested in my environment) although I would highly recommend to wait for the development team to provide the patch, since something like this is unsupported.
select * from prlock where prrecordid = <investment internal id>
prrecordid maybe inv_investments.id or it may be a lock and table for something else entirely; this is not a safe way to proceed.
I agree with you Nick! it's not safe at all.
If you use the first part of query being executed by security.locks you could infer that adding prtablename = 'SRM_PROJECTS' plus the pruserid that has it blocked could leave you in a safer place... still not safe at all... and would recommend to wait for that patch from the dev team as I suggested previously.....
select n.name COLLATE Latin1_General_CI_AS_KS name, i.code COLLATE Latin1_General_CI_AS_KS unique_name, l.prlockedsince, l.prtablename, l.prname, l.prrecordid,
r.full_name full_name, r.email email_address
from prlock l,
where n.lookup_code = l.prname
and n.lookup_type = 'CMN_LOCK_TYPE'
and n.language_code = 'EN'
and l.pruserid = r.user_id
and i.id = l.prrecordid
and lookup_code in ( 'prImportExport', 'prMethod', 'prUpdateTasks' )
select n.name COLLATE Latin1_General_CI_AS_KS name, t.unique_name COLLATE Latin1_General_CI_AS_KS unique_name, l.prlockedsince, l.prtablename, l.prname, l.prrecordid,
and n.language_code = 'EN'
and t.id = l.prrecordid
and lookup_code in ('~prTimeEntry' ) union
select n.name COLLATE Latin1_General_CI_AS_KS name, '' COLLATE Latin1_General_CI_AS_KS unique_name, l.prlockedsince, l.prtablename, l.prname, l.prrecordid,
and lookup_code in ('SCHEDULE_JOB' ) union select n.name COLLATE Latin1_General_CI_AS_KS name, cast(l.prrecordid as varchar) COLLATE Latin1_General_CI_AS_KS unique_name, l.prlockedsince, l.prtablename, l.prname, l.prrecordid, r.full_name full_name, r.email email_address
and lookup_code not in ( '~prTimeEntry', 'prImportExport', 'prMethod', 'prUpdateTasks')
^ or you could just look on that security.locks page - not sure why you are trying to find a complicated SQL solution for this?
Thank you for all your inputs.
Suman told me that the bug also exists in v14.2, so even if we run v14.1 I hope this information will calm down the problem on customer site.
I am going to remember the customer the security.locks page as a workaround, but he may be reject this and we may need to run SQL solution to solve this.
SQL commands I see in this post are not safe. So if the customer requires it, I will trace what does the security.locks page and reproduce the same thing.
I'm seeing this even when using the Clarity Gantt view as well, not just Workbench. Is the bug limited to Workbench, or is my experience with projects locking up while only using Gantt view part of the known problem?
P.S. This forum is great!
The lock should appear whilst someone is using the Gantt though ; the "bug" was that the lock was not being released at the end of the OWB session when it should have been.
So are you saying that the Gantt session is not releasing the lock correctly when the Gantt is closed/saved (and in what version)? You might want to talk to support if that is the case? (or hope someone from support might add to this thread with some info).
That’s correct. The lock remains after Gantt view is closed/saved. We are running 126.96.36.199 03 10. I’ll open up a ticket momentarily if there’s no response here.
Retrieving data ...