kevind
Active Member
I was more than willing to "pony up", how b'out U?
Posts: 639
Gender:
|
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.
|