---

 Comments

---

The problem was caused by the change detection in the engine. The way it was working, it was possible for an index page buffer to become "double-pinned", which means that the engine thought that it was being referenced twice instead of the correct once. Due to this issue, the index page buffer would not get flushed to disk even when it was considered "dirty" by the buffer manager, thus leaving the old copy of the index page in place in the .idx file and causing corruption. This issue is fairly serious, so it is recommended that anyone using any versions of 4.x prior to 4.15 upgrade to 4.15 immediately.

The specifics on how this issue can be reproduced are as follows:

1) Open a table and place a filter that will encompass at least a few rows from the table and is on an indexed field in the table (it is optimized).

2) Using an SQL DELETE query, remove all rows from the table.

3) Re-insert the same rows using an INSERT query.

4) Refresh the table with the filter, thus causing the filter to be re-evaluated. At this point the change detection will kick in and the issue with the index page buffer being pinned twice will occur.

5) Repeat the DELETE and INSERT and the index is now corrupted.

It is important to note that this problem only occurs when all of the above take place within the context of the same session. In other words, all of the TDBISAMTable and TDBISAMQuery components used above must be hooked up to the same session. The problem doesn't occur if the above operations are executed with multiple sessions.

---

 Resolution

---

Fixed Problem on 12/1/2004 in version 4.15 build 1