I know we always complain about locking, but we have run into the locking not working and causing a problem twice that we can pinpoint.  When we are in AP-C. enter purchase order invoices, we were inbetween answering the questions: Do you accept this entry and do you wish to close out the PO?  Another user went into AP-A to retrieve the same vendor's phone number.  It alerted the first user in AP-C that they were locked out by another user.  
 
In this instance the user in AP-C answered no to do you want to go on.  We were kicked out totally.  Looked in GL and the invoice was not in the batch.  Tried to reenter the invoice and we got the error message, no open orders before 11/30/04.  Went into PO and the po was closed out.  Invoice not in aging.
 
It seems like the 2nd user in AP-A should have been the user locked out since the invoice process was already started.
 
As I said before, this is at least the 2nd time this has happened.
 
Thanks

A truly relational database and structure is not REQUIRED to eliminate record locking conflicts.
 
For 15 years, I Maintained an Accounting / Inventory / Order Entry system for an Alpha-Micro System.  As shipped, this software was riddled with file / record locking problems because the developers did not understand the most basic concepts of locking.  Luckily, It came with full sources.  
 
In many cases, record locking was completely ignored because of a fundamental misunderstanding of the difference between 'Operating system level' and 'Application level' file and record sharing.
 
Transactional Record locking boils down to two fundamental rules.
These address 99.99% of record locking problems:
 
1. Never lock a record and then expect some kind of user action before unlocking it.
2. Always update records with a lock-read-modify-write-unlock sequence.  
 
Example:
a. User displays MRP info for an Item.  This record is read WITHOUT a lock.
b. ReOrder Level is modified.
c. Save is clicked.
d. Record is Re-Read WITH a lock (this will refresh any fields that were modified by other processes / users), The changed field is applied, the record is written, and Unlocked.
 
The IS Tech developers know this.  We have already seen the benefits in many places.  Unfortunately, it takes a really long time to ring all of these out.  In many cases it means a change to program flow and/or logic to make it work correctly.

Kevin/Lynn,
 
Of COURSE that is correct. HOWEVER, the wonders of a relational DB,  means that the challenge/response rules are maintained and managed by the DB, NOT by the application code per se. THAT is what I was getting at.

You all are way beyond me.... but thanks.
 
I will need to modify EVO to add PO-P.  
 
Lynn, is there a way the updates could have these added menu items already in them?  If not, maybe a good procedure to follow each time.
 
Thanks