timeadmin.TIMESHEET_LOCK_ERROR

[Karthik Aitha]

Dear All,
I'll need your help for the below issue.

In my application (Clarity PPM - 15.7.1), Users are not able to adjust the timesheets that are already posted and receive below error. There are no duplicate timesheets, time periods are opened, project task has time entry enabled and so is resource.

timeadmin.TIMESHEET_LOCK_ERROR

Could you please help?

Thanks

[Jose Ignacio Mugica]

Could you check if the timesheets erorring out are locked on the prlock table?
1. Run the following query:
--Oracle
select * from prlock
where (prtablename = 'PRTIMESHEET'
and prname = '~prTimeEntry') or (prtablename = 'SRM_RESOURCES' and prname = '~prTimesheetCreate')
and prlockedsince < sysdate - 0.042

--MSSQL
select * from prlock
where (prtablename = 'PRTIMESHEET'
and prname = '~prTimeEntry') or (prtablename = 'SRM_RESOURCES' and prname = '~prTimesheetCreate')
and prlockedsince < getdate() - 0.042

2. If the query returns any results, run this query:
--ORACLE
delete from prlock
where (prtablename = 'PRTIMESHEET'
and prname = '~prTimeEntry') or (prtablename = 'SRM_RESOURCES' and prname = '~prTimesheetCreate')
and prlockedsince < sysdate - 0.042;
commit;

--MSSQL
delete from prlock
where (prtablename = 'PRTIMESHEET'
and prname = '~prTimeEntry') or (prtablename = 'SRM_RESOURCES' and prname = '~prTimesheetCreate')
and prlockedsince < getdate() - 0.042

Regards
Joxi

[Karthik Aitha]

Thanks much, Jose.

I found there is one record locked since 2nd Oct and the User ID belongs to the same entity who has complained this timesheet lock issue.
I'm wondering, why 1 record (resource timesheet) is impacting all entity (they are in same project) and why this happens actually?

I'm yet to execute delete query. I'll wait for your reply before I proceed onto delete.

Thanks,
Karthik

[kevin virlombier]

Hi Jose,

We try your solution but we still have the issue with an other resource. We delete the resource resulting to your query given upper in prlock table, but after the deletion another record replace it in the table and issue is still the same.

Can you please assist us and give us advise on how to solved this issue or if you have other solution in order to solved the issue ?

Thank you.
Kévin.

[Jose Ignacio Mugica]

Hi Kévin,
Nice talking to you.
The issue was at the end due to a prtimesheet lock entry for one user that was preventing every user's timesheets from being adjusted.
As we cleared that specific lock, the timesheet adjustment was fine.
Additionally this was only affecting Modern UX timesheets, Classic UI timesheets were OK.
À bientôt
Joxi

[kevin virlombier]

Hi Jose,

We try your solution but we still have the issue with an other resource. We delete the resource resulting to your query given upper in prlock table, but after the deletion another record replace it in the table and issue is still the same.

Can you please assist us and give us advise on how to solved this issue or if you have other solution in order to solved the issue ?

Thank you.
Kévin.

[kevin virlombier]

Hi Jose,

We try your solution but we still have the issue with an other resource. We delete the resource resulting to your query given upper in prlock table, but after the deletion another record replace it in the table and issue is still the same.

Can you please assist us and give us advise on how to solved this issue or if you have other solution in order to solved the issue ?

Thank you.
Kévin.

[Jose Ignacio Mugica]

Hi Kevin,
A time entry lock is temporary and should be released immediately from the the PRLOCK table.
Check the timing of the lock. On the security.locks URL you will get some info about the lock timing.
Can you check what was happening around that time? Any DB connectivity issue?
As it happens often, anything common around the times the lock appears? Any Clarity job combination being run? Any DB maintenance activity on going? 
Alternatively to remediate clear the lock from the security.locks  URL itself
Regards,
Joxi

[kevin virlombier]

Hi Jose,

The solution you give, clearing lock from security.locks is solving the issue, thank you for the workaround. To answer you're question :

Can you check what was happening around that time? Nothing especially we still use it in the same way.
Any DB connectivity issue? Nothing specific related to DB, the DB is available and are fine.
As it happens often, anything common around the times the lock appears?  Nothing special to the action done for the lock timesheet issue we met
Any Clarity job combination being run? I am not sure but as I know no job running at the same time
Any DB maintenance activity on going? No maintenance ongoing at the time we met the issue.

As I already said thank you for the support you bring for us and the solution you give.

Regards Kévin