Introduction

---

DBISAM automatically uses the proper change detection when dealing with updates to tables. However, there are two different types of change detection policies that can be used when dealing with reading data from tables:

   Strict Change Detection
   Lazy Change Detection

The choice of which policy to use is up to the developer and his/her needs and can be controlled via the TDBISAMSession StrictChangeDetection property. Also, any time DBISAM checks for changes in a given table it acquires a read lock on the table so as to ensure that no other changes occur while DBISAM performs the actual checks. Please see the Locking and Concurrency topic for more information.

Strict Change Detection

---

Strict change detection uses a "brute-force" method of determining whether the data has been changed by session during the process of reading data from a table. What this means is that every operation that requires reading of data from a table such as moving between records, filtering, setting ranges, searching, etc. will cause DBISAM to check for changes before the operation is executed. If DBISAM finds that the data in the table has changed, it will dump the contents of its local cache and refresh it using the latest data from the table. This can have some very significant performance implications, especially when the table resides on a network file server, so you should use this policy only when it is absolutely necessary that the data being read is always up-to-date at the time of the operation. It also tends to completely defeat the local caching done by DBISAM if there are a lot of updates taking place concurrently on the same tables. Please see the Buffering and Caching topic for more information.


Lazy Change Detection

---

Lazy change detection is the default change detection policy and is the most desirable in terms of efficiency and performance. Lazy change detection works by only checking for changes by other sessions when DBISAM cannot find the desired data locally in its cache and must physically read the data from the table. If changes are found, DBISAM will dump its cache and retry the read operation that it was in the process of executing when it found that it needed more data from the table. Because of the fact that DBISAM can cache a fairly large amount of data for each table open within a session, this policy tends to be very efficient and will provide the best performance overall. However, it does leave the job of refreshing data up to the developer so please take this into account when developing an application using this change detection policy.


Updates and Change Detection

---

DBISAM always uses a strict change detection policy when performing updates. This means that anytime you append, edit, or delete a record DBISAM will automatically make sure that it's local cache contains the most up-to-date data before performing the actual update operation. In addition to this, DBISAM also performs a record buffer comparison when editing or deleting records to make sure that the record that is now present in it's cache is consistent with the record that was intended to be edited or deleted before the operation was initiated (i.e. it's what the user sees). If the record is not the same due to a change or deletion by another user or session, DBISAM will trigger the error DBISAM_KEYORRECDELETED indicating that the record has been changed or deleted by another user and the operation will be aborted. This record buffer comparison also includes the comparison of BLOB "signatures" in the record buffer so it is safe when determining if BLOB fields have changed also.