Icon Frequently Asked Questions

My customer has sent me a table that has become corrupted. How did this occur ?

DBISAM is susceptible to corruption caused by someone (or something like a power outage) physically turning off the machine that is running the application using DBISAM. The circumstances in which this type of failure occurs and the open mode of the table(s) (exclusive or shared) will determine what type of corruption you will encounter, if any. For example, if DBISAM is in the middle of adding a record to a shared table when the power goes out, the record being added will definitely be lost. However, due to the caching involved and the fact that the buffers don't actually get flushed until after the append operation, there's a large chance that there also won't be any corruption. Corruption will likely occur if the failure occurs while the buffers are getting flushed to disk and the flush operation does not complete or only half-completes. Keep in mind that when a table is opened in exclusive mode cached data will get flushed to disk in a seemingly random manner so corruption is much more likely after a failure in such a situation. If you think you have corruption in your table(s), you should immediately verify and/or repair the table.

Information It is important to distinguish between the term flush as it is used above from the actual process of the operating system flushing the data physically to disk. The term flush is used above to mean that DBISAM instructs the operating system to write the data to the designated file. This does not mean that the operating system will necessarily actually write the data to the file on disk. However, you can force the operating system to flush the data to disk in order to eliminate the potential for corruption due to this write caching at the operating system level. Please see here for more information about buffering and caching in DBISAM and the operating system.
Image