` Comment on an Icetips Article
Icetips - Templates, Tools & Utilities for Clarion Developers

Templates, Tools and Utilities
for Clarion Developers

Add a comment to an Icetips Article

Please add your comments to this article. Please note that you must provide both a name and a valid email address in order for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!

Your Name:  
Email:  
Header text/Subject:  

Please enter your comment in the box below:

Back to article list   Search Articles     Add Comment     Printer friendly     Direct link  

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.


Today is November 23, 2024, 2:02 am
This article has been viewed 35223 times.



Back to article list   Search Articles   Add Comment   Printer friendly

Login

User Name:

Password: