When I select multiple documents in Web Access, usually more than 100 to update metadata, it gives 'Entry Locked (9014)' error. It is not happening consistently. Any thoughts please?
Sam,
When the customer opens up the repository, there are no documents locked. When they select 10 or more and start updating metadata, the error starts popping up. Under what cases, will this happen please? Do you think the customer is going fast with their actions?
Do they need to select documents in Web Access, wait a minute or so before they can start updating metadata?
Thanks
Priya
Thanks Sam.
I'd start with checking the Entry Locks list in the Laserfiche Administration Console to see the source of those locks.
The Entry Locks listing provides the name of the document that is currently locked, the document's repository path, the user who initiated the entry lock, and the date and time the lock was applied.
Should provide a starting point.
Although keep in mind that these locks can be very short-lived, so they may be gone by the time you look. Especially if you have Workflow or similar operating on these documents, it can just be a matter of trying to modify it in the same few seconds that another process is updating it.
The only reason for a lock is to gain exclusive access for a modification, so if you have auditing turned on you might be able to tell who or what is operating on these documents at the same time.
Thanks. Yes, I know who is operating this. Is it normal for Web client to do this when users are updating metadata for multiple documents at same time?
Whenever you attempt to modify an entry, the system will first acquire a lock on that entry, so that it doesn't have to worry about reconciling changes from another user or needing to tell one user that it can't save their work because of conflicting changes. If you are updating multiple entries, it will attempt to lock all of them.
Ok. So, if we wait for it to complete, locks will automatically get cleared and document metadata will be updated for all documents? Thanks.
The user or process that had the lock that blocked the user should shortly release that lock. At this point, If the user attempted to update the metadata again it should succeed, though there wouldn't be a visual indication that the other user had released their lock and they are "at this point".
Is it possible to design your processes so there aren't multiple users attempting to update the same document?
Thanks. In this case, it is end user who is manually updating metadata for multiple documents in production repository web access. She gets this at 7am when there is not much load on the system.
When we do this in our Staging environment, it works fine. In production, it throws this error and does not complete the update.