Database Error 109, DeleteLock

[micbar]

We are getting error 109 when updating a change order does anyone know what this could mean or a fix, It locks the user out of the change order saying its locked for edditing by them. The only way we have found to get around it when it happens is to wait a while or re-boot the vault server.

9/23/2014 1:48:51 PM *******************************************************************
Error: Soap Exception ( mesg-id = 635470769317647920 )
Exception: DatabaseError [109]
Stacktrace:
Server stack trace:

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Connectivity.Process.Services.ChangeOrderService.UndoEditChangeOrder(Int64 coId)
   at Connectivity.Web.Services.v19.ChangeOrderService.UndoEditChangeOrder(Int64 changeOrderId)
   at SyncInvokeUndoEditChangeOrder(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

Exception(Inner): DeleteLock: The user does not own the existing lock on the entity.
Stacktrace(Inner):    at Connectivity.Core.Database.TransactionContext.OnSqlException(SqlException e)
   at Connectivity.Core.Database.SqlAccess.ExecuteReaderInternal(SqlCommand cmd)
   at Connectivity.Core.Database.SqlAccess.ExecuteReader(CommandType commandType, String commandText, SqlParameter[] commandParameters, Int32 commandTimeout)
   at Connectivity.Core.DataAccess.Director.InvokeCommand()
   at Connectivity.Core.DataAccess.Director.Execute(Options options)
   at Connectivity.Process.DataAccess.ChangeOrders.UnLockChangeOrder(Int64 coId, Int64 userId, DateTime loginTimestamp)
   at Connectivity.Process.Services.ChangeOrderService.UndoEditChangeOrder(Int64 coId)
   at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

[minkd]

I assume from the stack trace that you are using Vault Pro 2015.

In that case, in Vault Explorer in the Actions menu, invoke the "Clear Item and CO Locks" command. This will immediately clear any locks and/or uncommitted item edits for the logged-in user.

-Dave

[micbar]

Yes we are and thank you, is there any way to prevent it from happening all together? Do you think it has anything to do with timing of our vault backup still running from overnight (its been taking 11 to 12 hrs to back up the vault so its running until 10 or 11 am.)

[minkd]

If your backup script is doing an iisreset, then that would be a problem.

Also, avoid having IIS recycle the worker process during regular business hours if possible.  Any recycling of the worker process will result in roughly the same behavior as an iisreset.

-Dave

[micbar]

This :

I assume from the stack trace that you are using Vault Pro 2015.

In that case, in Vault Explorer in the Actions menu, invoke the "Clear Item and CO Locks" command. This will immediately clear any locks and/or uncommitted item edits for the logged-in user.

-Dave

Did not solve the problem because the general user can not do this command, it errors out over permissions i think?

We use single sign on with windows accounts, any of those seem to error out but if i log in with a vault only user id the command works. Also is there a way to stop it from happening like a timeout set someplace? seems like if we wait 15 - 20 mins then try and push the change order on it will work.

[minkd]

Any users with an item editor role (level 1 or level 2) should be able to clear their own locks (which they needed in order to get the locks).  However, users cannot clear the locks of another user.

I'm not sure why it wouldn't work when using active directory authentication.  Do those users have an item editor role?  If not, how were they able to get item locks in the first place?

-Dave