We had a power outage which may have something to do with this problem.
Our sales clerk was releasing sales orders one by one when the power outage occurred.  When the power returned, she started over because she assumed that none of the sales orders had been released.  She was able to release all but one, which Evo tells us is locked by another user:  The record in file: BKARINV is locked by another user.  Do you wish to try again?
Trying again brings back the same locked record message.
 
Having everyone exit from Evo has no effect.
 
How do we unlock the record?
 
Paul Groh

Quote from Lynn_Pantic on 11/16/10 at 21:02:49:

Jordan was in AP-c and we had something similar to this happen today with a PO history file.    
 
I am not sure what to do as we are on the amazon server.  
We can see the receiver in AP-C but told it is not there.  Jordan was in AP-C when this happened.  
 
Anytime we go into PO-D and try to view that particular receiver we get the "locked by another user BKAPHPOL " message.  Weirdly we can review all  other PO receivers, It seems that the only thing corrupted is that one single receiver.  Jordan continued paying other invoices and everything else is working.
 
When you get stuck by this in PO-D you can't say N to terminate.   Yes or No gets you nowhere so I have to Control Alt End to get out of PO-I-D.  I have done this over and over and sometimes we get the message.
 
Warning ERR file T7POA.src  line 4434
 
"There active modal form which need to first be needed to be exited"     This sentence makes zero sense to me.
 
Edit:   An hour or so later I was scrolling thru maintaain database  BKAPHPOL when I noticed the PO 208222 said it was locked by another user.   We were having problems with 208218 not 208222.   208218 was causing our problems but it seemed fine in maintain database.    I exited maintain database and went to the user's workstation and he was not  in 208222.  But just in case I control Alt End and signed out and now weirdly I am no longer getting the locked message in 208218.  So I suppose 208222 was somehow causing 208218 problems.   Note 208219, 208220 nor 208221 had been received yet.
 
All seems to be well.   PO-D no longer locks up with 208218 and we were able to use AP-C to create invoice for 208218 and print the check.