Hi Will Hefner 

Will Hefner said:

Sometimes, a user can lock themselves into a record - leaving that record unable to be changed/modified.

If can see only 2 scenarios where this happens:

• The user is using jump-to, possibly multiple ones, to access another records. In that case, there are no solution to prevent this lock to happen.
• The user has multiple browsers opened, maybe 1 on the work order function and another on the production tracking, in that case we would need to change the record read by the 1st browser using the work order functin (or close the function) to remove the lock.

Aree you facing another scenarios, where users are locking themself? 

Most of the time, they are backing out of a record improperly i.e. using Chrome's back button instead of X3's "close page" button. This causes them to be locked into a record (let's say, a work order), even though they are no longer in the work order screen. So, when a different user attempts to change/modify/push through that same work order - they will get the error message "change in progress on another workstation".

When this happens, our procedure is to use X3's "locked symbols" tab and close their session out so that they are no longer locked in that order. However, our hope is that there could be a way for any user, regardless of permissions/access, to clear their own locked symbol - or disconnect in web client sessions. As of right now, we do not know if such a thing is possible.

Something to consider - if the session has been closed or is no longer active then you can look at automating the removal of the APLLCK record using this script:

DELETE FROM x3.LIVE.APLLCK WHERE LCKPID_0 NOT IN (SELECT X3SM0.SESSIONID_0 FROM x3.X3.ASYSSMDBASSO X3SM1 JOIN x3.X3.ASYSSMINTERN X3SM0 ON X3SM1.SESSIONID_0 = X3SM0.SESSIONID_0 JOIN sys.dm_exec_connections VDS ON VDS.session_id = convert(integer, X3SM1.DBIDENT1_0) AND VDS.connect_time = convert( datetime, X3SM1.DBIDENT2_0, 121));

Details on how this was derived are available in this PDF.

Standard provisos apply - use at your own risk, your mileage may vary, etc.

What we are trying to figure out is how to close the session in the first place. At this time, Only our ERP team can do so.

A follow-up to my previous message - of course the script only clears APLLCK records where the user session is no longer present. If the user closed their session incorrectly and left the process running, then it would still be necessary to kill the process, which ultimately brings us back around to the original request re: how to let users kill their own session.  :-/