Use AttachInsteadOfLock and DetachInsteadOfUnLock methods

The use of AttachInsteadOfLock and DetachInsteadOfUnLock is recommended only in certain situations. Advanced knowledge is required to properly use these methods. These methods are typically used with tables that have a parent-child relationship where updates to the parent record require updates to the child records (for example, a pipeline is composed of multiple pipe segments). When the parent is locked, then the child is attached with the assumption that the lock on the parent will block updates to the child without the child having a real lock.

Additionally, these methods can be used when different parts of an application take locks on either a table or a record and hold those locks. It is then possible to attach to the table or record at different points of the application because it has been previously locked; however, this practice is, again, strongly discouraged. It is safest to pass the instance of the locked record or table object down into dependent parts of the application, allowing the object to indicate the proper locked state.

If double-buffering is enabled on the system, there are two copies of the record in memory. As a result, indeterminate behavior can occur if either a record attach does not match the lock type taken by the application, or if another application or thread has a lock on the record. For more information on double-buffering support, refer to "Appendix C: RealTime Database (RTDB) Configuration Settings" in volume 1 of the AVEVA Enterprise SCADA RealTime Administrator documentation.

See the following scenarios for examples on recommended locking best practices:

• Create a record
• Read a record
• Update a record
• Read records with a parent-child relationship
• Convert a lock on a record with a parent-child relationship