You are viewing limited content. For full access, please sign in.

Question

Question

Entry Lock from queries

asked on July 4, 2018

We have had a problem with some of our workflows wherein performing a query, followed by some action on the entry (rename, move, etc.) intermittently results in an entry lock and a failure to perform the action.  In the entry below, I perform both repository and DB queries as part of an automated data check / data retrieval process in a loop for a multi-value field.  After the loop has completed, I rename the entry with the retrieved data:

 

 

You can see where the error occurs on the rename entry action.  This causes the system to wait, then retry the rename action after 5 minutes.  The problem this kind of issue is causing us is that, the way our QA system works, by the time that 5 minutes is up the file might have been approved for filing and sent to permanent records storage.  When this workflow resumes after the 5-minute wait, it pulls the document back out of Records and into QA Review, because that's the status the document had at the time.

 

I recognize a number of workarounds: I could do yet another query before filing to find the entry's current location or status, or possibly even just move the Rename function.  However, we really want to answer the larger question of getting around these intermittent entry locks.  It doesn't happen every time, but it can mess up our records when it does. 

 

Does anyone have any suggestions on getting around entry locks?  Like maybe putting something in to force the Rename function to wait until the queries have completed, or making the workflow cancel if another instance with the same entry is waiting on a locked resource?  This has been a problem with a couple of our workflows now, and while we are typically able to find workarounds, I would much rather find a solution to the overarching problem.

0 0

Answer

SELECTED ANSWER
replied on July 4, 2018

Hi Sean, 

 

If you input the following in your search criteria, it should bypass any documents that are locked:

 - ({LF:CheckOutUser="*"})

 Basically, at the end of your Search Criteria, to skip any locked documents, you need to add the above and see if that helps? 

 

Thanks

Ziad

3 0
replied on July 5, 2018

Great tip!  Thanks!

0 0

Replies

replied on July 5, 2018 Show version history

Sean,

I'm more inclined to believe that a user is responsible for the lock. Based on the screenshot you provided there is nothing in the previous steps that were actually reached that would result in a lock on the entry.

Because the users have access to the documents, the most likely scenario is that a user has the document open with unsaved changes resulting in a lock.

I do not believe searches or queries are even capable of locking documents as locks should only occur when a user or process is actually changing the document in some way.

2 0
replied on July 5, 2018

You're right, searching does not lock documents. Queries against data sources have no bearing on the lock status of a Laserfiche document.

If it was a lock from a workflow, then it would have to be from a different instance.

0 0
replied on July 5, 2018

Thanks for the reply!  It's good to know that queries are probably not the locking source.  It could be that the queries are simply taking too long to complete, so when the user initiates another instance of the workflow the query hasn't completed... that would make sense.  Thanks again1

0 0
replied on July 5, 2018 Show version history

There are a lot of factors to consider, such as what events trigger the workflow. Based on that information, you can try to find ways to prevent the process from hitting the same documents more than once.

Ziad's tip could help, but depending on how long it takes to complete the search and loop through documents, someone might acquire a lock after you already have the results.

One other trick I use is to put a Find Entry activity right before the step that could hit the error and retrieve the "CheckOutBy" and "LockedBy" properties. If either of those are not empty then the document is locked by another user/process.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.