Par2: Btrieve -- Internal structure 1998-05-20 -- Bill Knopf Btrieve stores indices and records in "pages" which can range from 512 bytes to 4096 bytes in size. At the beginning of each page, Btrieve stores the location and length of the valid (used) areas within that page. It doesn't waste the time to initialize the unused areas of the page to zeros. Thus, the apparent garbage data in unused areas of the pages. You will also notice that the physical size of a Btrieve file is larger than the sum of the data stored in the file. This is because of the unused page areas and the page maps. One of the reasons that Btrieve is so reliable is that when it updates a record or an index, it never directly overwrites the old page which is being updated. Btrieve uses a page map to point to all of the active pages. Actually, there are two page maps. The header record at the beginning of the file contains a pointer to the active page map. When an update is made to the file, all of the record and index pages which are changed are written to an unused location in the file, and the secondary page map is updated. In the secondary page map, the old page locations are marked as unused. When all of the changes have been written to disk, the header record is updated to swap the pointers to the primary and secondary page map. Then the secondary page map is synchronized with the primary page map. Because of all this, Btrieve is impervious to power failures and server abends. The most that you can lose is the last transaction, which, BTW is written to MKDE.TRN before it is written to the data file. I have learned to treat Btrieve files as a black box. As long as Btrieve stores and retrieves data reliably, I don't care Btrieve accomplishes it. Printed November 21, 2024, 6:33 am This article has been viewed/printed 35219 times. |