|
Hi: The program-enforced locking system used by CA's PRMS (I believe sold by CA since we last paid for maintenance) is to create a record in a locking file that has the User ID - alternatively the workstation, depending on module - and all of the key field values necessary to uniquely identify the "locked" record in the data file. When that record is no longer in use, the program that was using it deletes the locking record. Any program that can update the data file must first check the locking file. If a matching locking record is found, the program cannot proceed; the user (if interactive) is notified; and a "soft landing" is performed as necessary and appropriate. Importantly, this system can be used to enforce relational integrity programmatically. Even when a record is not locked by the operating system, it can be protected from changes that would affect other files (such as deletion of a record in a header file when related records in a detail file exist). This approach is the safest, if properly implemented, I think. However, it really ratchets up the complexity of programs that open and modify multiple related files. Maintenance is a degree of difficulty greater than otherwise equivalent programs. Darrell Darrell A. Martin - 630-754-2187 Manager, Computer Operations dmartin@xxxxxxxxxxxxx midrange-l-bounces@xxxxxxxxxxxx wrote on 10/24/2006 01:03:03 PM:
So it seems like Chris' approach, or something similar, will always be the safest bet since the time between chain and update will always be minimized (nearly eliminated). The user who retrieves a record for maintenance and wanders off somewhere, won't prevent a process from proceeding by locking a record. The posting routine may delete records, so I'll need to take that into account, as well as an update that changes the record from another
source.
This will take some time to change the program but seems the best all around approach. I'll dig into the archives for examples. Thanks. Pete
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.