Clarity

 View Only
Expand all | Collapse all

CA Clarity Tuesday Tip: Time Sheet Locks

  • 1.  CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Sep 27, 2011 07:53 PM
    Title: CA Clarity Tuesday Tip: Time Sheet Locks

    CA Clarity Tuesday Tip by Shawn Moore, Sr. Principal Support Engineer for 09/27/2011

    In Clarity there are a couple of different timesheet locks that can occur for different circumstances.

    The common errors/warnings generated by these locks are:

    TMA-0111: Error updating timesheet. Couldn't obtain lock. Click browser's back button and try again.
    TMA-0118: This timesheet's status has been locked by the process engine. It can only be changed by an action item.

    Both of these locks are caused by different conditions and are stored in different locations in the database.

    1) TMA-0111: This message is due to a timesheet update lock, which is generated during the time the timesheet is being saved. The life of this lock should be milliseconds but it can persist if the system encounter a deadlock or if the system was backed up at the time the timesheet lock was created and restored to another system. This lock can be found under the PRLock table.

    i.e. to view all prlock timesheet save locks:

    select * from prlock where prtablename = 'PRTIMESHEET'
    and prname = '~prTimeEntry'


    2) TMA-0118: This message comes from a process based lock, which has a duration that is user activity based. Once a user submits a timesheet in a timesheet process, some set of approvals typically will allow the process to complete and the lock to be freed up. (Since processes can be user defined I won't go into detail on the process itself.) This lock is found in the odf_locked_attributes table.

    i.e. to view all process based timesheet locks:

    select odf_locked_attributes.id, first_name, last_name, prstart, prstatus, odf_locked_attributes.odf_pk,
    prtimesheet.prid
    from odf_locked_attributes, prtimesheet, prtimeperiod, srm_resources
    where object_code = 'timesheet'
    and attribute_code = 'prstatus'
    and odf_locked_attributes.odf_pk = prtimesheet.prid
    and prtimesheet.prtimeperiodid = prtimeperiod.prid
    and srm_resources.id = prtimesheet.prresourceid

    Note: At some times you may need to clear out locks. It is best to contact support if you do not know how to do so and we can guide you through the appropriate steps.

    Enjoy!

    -shawn


  • 2.  RE: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Sep 27, 2011 10:39 PM
    Thanks again.

    Couldn't 1) TMA-0111 also be created when the server is busy running a heavy job like data mart extraction? If so then the lock could persist longer couldn't it?

    I've encountered 2) TMA-0118 in systems where I have just timeentry right. When there was an error which I wanted to adjust there was nothing I could do until the approver had processed the timesheet, becaue of the lock.
    Not having rights nor access to the database the only solution was to email to the approver to process the timesheet or to return it.

    Martti K.


  • 3.  RE: CA Clarity Tuesday Tip: Time Sheet Locks

     
    Posted Sep 28, 2011 09:42 AM
    Thanks Shawn (and Martti) for the great info!

    Chris


  • 4.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 17, 2014 07:59 AM

    I've recently encountered TMA-0111 in disguise:

    An approved time sheet does not get posted no matter what I try. Don't get any error either.

    When going back to the time sheet and trying to return that I get the error. Sure enough there was a lock on it.

     

    Have seen the error about the lock also before.

    The situation was the same, but unfortunately do not recall which action gave the error.

     

    Yes this is an old thread, but so is my Clarity version (r8)



  • 5.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 17, 2014 09:58 AM

    ^ is the time period open? (I recall that that stops posting).



  • 6.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 17, 2014 11:54 PM

    Can you check the status from db apart from what Dave has mentioned ?

     

    NJ



  • 7.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 18, 2014 03:57 AM

    The time period is open, but at least in this version of Clarity approved time sheets from closed periods are posted. We do it all the time: close the time period right after approval while we wait for the mandatory 5 minutes in order to stick to the dead line and to avoid delays with users approving their timesheets during that wait period.

    There is definitely a time sheer record in prlock. We had this before, so it does not take very long to recognize it when we have it again. Then just delete the record. For some reason it does not display in security.locks as I should expect.



  • 8.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 18, 2014 04:02 AM

    When you say "For some reason it does not display in security.locks as I should expect.", do you mean that it is there in prlocks table, but not displayed on the security.locks page ?

     

    NJ



  • 9.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted Nov 18, 2014 04:17 AM

    Yes, if it did it would be easy to find for beginners and without db access as well.



  • 10.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted May 18, 2018 07:31 AM

    Hi urmas,

    You can apply the query without DB access.

    i.e. you can use the update query in GEL scripting.

    Example -

    1. create a process from Administration

    2. Create custom typescript.

    --------------------------------------------------------------------------------------------------------------------------------------

    <gel:script xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:core="jelly:core"
    xmlns:gel="jelly:com.niku.union.gel.GELTagLibrary"
    xmlns:soap="jelly:com.niku.union.gel.SOAPTagLibrary"
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:sql="jelly:sql" xmlns:xog="http://www.niku.com/xog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <!-- *******************************-->
    <!-- Get and Check DB Connection to Clarity -->
    <!-- *******************************-->
    <core:catch var="errorVar">
    <gel:setDataSource dbId="niku" var="dataSource"/>
    </core:catch>
    <core:choose>
    <core:when test="${errorVar == null}">
    <sql:query dataSource="${dataSource}" var="dual">select 1 from dual</sql:query>

    <!-- <core:if test="${debug}"> -->
    <gel:out>Database connection established</gel:out>
    <gel:log level="INFO">Database connection established</gel:log>
    <!-- </core:if> -->
    </core:when>
    <core:otherwise>
    <gel:log level="ERROR">Database connection NOT established</gel:log>
    </core:otherwise>
    </core:choose>
    <sql:update dataSource="${dataSource}">
    update SRM_RESOURCES
    set DATE_OF_TERMINATION = to_char(sysdate,'YYYY-MM-DD')
    where unique_name = ''
    </sql:update>
    </gel:script>

    ---------------------------------------------------------------------------------------------------------------------



  • 11.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted May 18, 2018 08:14 AM

    Caution : Unsupported database updates are still unsupported whether you apply them directly to the database or via the UPDATE tag in GEL.

     

    (also the update sql you have given is not very good - you are setting a DATE field to a CHAR value and hoping that it matches ok. You should really be casting the date-time to a date - eg TRUNC(sysdate) or providing an explicit date, i.e. use to_date)



  • 12.  Re: CA Clarity Tuesday Tip: Time Sheet Locks

    Posted May 18, 2018 08:35 AM

    I agree with you David but there are cases where we need to perform some basic modifications.

    This is just an example to perform SQL update in GEL scripting though it's not recommended by CA