Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Icetips Article
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 21, 2024, 3:48 am This article has been viewed 35219 times.
|
|