247:, the number of pages in current use, the number of keys that can index the file, the number of records in the file and other details. After version 6.0 two FCRs were used for redundancy. A 32-bit usage count field that exists in each FCR is used to determine which FCR was valid to use. Each time an operation is done on a file the field is incremented. The FCR with the highest usage count becomes the valid FCR. The FCR is well described at source samples from Jim Kyle. With the introduction of MKDE version 8, the structure of the FCR page is changed. The page size is now moved within the FCR and is not a regular 32-bit field. Since version 8 you have to calculate the page size by taking the 32-bit field at offset 0x2A and multiply with 256.
125:. However, the file structure itself is largely built around smaller units of data, called "pages" in Btrieve. Though the structure has changed over the various versions of Btrieve, the file structure still revolves around a File Control Record (FCR) — which defines the configuration of pages — and pages in the Btrieve file that contain data. Historically, Btrieve used "physical pages", or pages that were located at fixed positions in the file. Beginning with version 6.0 "logical pages" started to be used, which were mapped to page allocation tables (PATs) — this allowed Btrieve to change their record update technique from what was later known as "pre-image paging" to a technique called "shadow-paging".
473:. User transactions are exclusive and concurrent transactions while system transactions are a bundle of non-transactional operations and/or user transactions. System transactions were exclusively used for data-recovery by the MKDE. If a system failure causes data corruption then when the MKDE is restarted it detects all the files that had a failed system transaction and tried to recover them. However, as user transactions might have been lost when the last system transaction was rolled back an option could be set that caused the MKDE to force system transactions that had user transactions to complete when the engine received an "End Operation" request.
490:
database. What physical techniques are used to accomplish this, i.e., ISAM, embedded pointers, etc., is almost irrelevant to the discussion. By contrast, a relational database does not provide the application layer with any way to "navigate" through the logical database structure and instead provides a set-level interface for selecting, aggregating and joining data. Relational databases may also use a variety of physical techniques to access data including the same mentioned above, but the important aspect of being "relational" is that the data is accessed relationally, i.e., vie a set query model rather than a navigational model.
22:
259:(PAT) maps the logical pages to the physical pages. Each PAT is just a physical page located at well-defined locations. Like the FCRs, PATs always occur in pairs, with the currently valid copy indicated by having a higher usage count. The first pair of PATs immediately follow the first two FCRs and takes up physical pages 2 and 3. A variable number of other pages follow, and a new pair of PATs in turn follow this. Each PAT has a fixed number of pointers to logical pages, with each entry that is empty having a value of zero.
291:
update be interrupted and only half the data written to the page, then the page would just be rolled back by the engine by copying the page from the pre-image file back into the corrupted page in the original database file, then the temporary pre-image file would be deleted. The preimage files were given the extension .PRE, so finding these files in the system usually indicated that a transaction had not happened correctly and recovery had not been successful.
165:
357:
396:
b-tree is kept for each index in the system, and the root node information is kept in the FCR. In
Btrieve 6.x a new index can be created at file creation time, or added and dropped after the file is created. Index pages are also created as they are needed. Before Btrieve 6.0 existing key indexes could not be removed, though supplemental indexes could be created and dropped as needed.
156:, and these pointers are contained in the record itself; ISAM, which is the fundamental structure of Btrieve, uses a secondary index table to store these pointers to decrease search times. Thus, the two types of database are different, and may or may not explain why Pervasive started using different terminology for classifying their database.
448:
locking. The advantages were obvious: more than one client could access the file at the same time, so long as they weren't trying to access the same record, leading to performance increases. Additionally, other clients could read the locked pages, and would not see any changes to a file involved in a
411:
of duplicate keys. This meant that the order of the duplicate keys in the list was in the order they were entered. The duplicate key method did not use a linked list, but rather made all the keys unique by creating a new index key and appending the address of the record pointer to the end of the key.
489:
This is not strictly correct. A navigational database is one in which the logical access to the data in the database is done via the application-level interface or API, It is navigational in the sense that logical relationships are traversed by the application code "navigating" its way through the
344:
approach would be able to allow for this fragmentation, but the
Btrieve engine would have a hard time reading through sequential records. Therefore, starting with version 6.1, a table is used in the file that stores pointers to each of the pages that make up the data record. This table is called a
290:
was used when performing updates to records. It involved the creation of a new "pre-image file" before the changes were made, and then the pages from the original data file were copied into this new pre-image file temporarily. Then the system would make the changes to the original file. Should the
395:
and are very efficient as a mechanism for fast data retrieval. The drawback of a btree is that data must be constantly balanced when it is inserted into the tree, therefore
Btrieve only stores the record index as btree to reduce the amount of time it takes to insert and update records. A separate
343:
In
Btrieve, each page is fixed but a record can be larger than the page size. This means that records often need to be fragmented and spread over many different pages. With very large records this can mean that many hundreds of pages may need to be used in order to store the record. A linked list
303:
because it still has not had its location written to the file's PAT. Once the update to the shadow page completed, the PAT was updated and the entry recorded in the PAT of the next available and current physical page in the file. However, if a system failure occurred while doing the update to the
452:
MEFS mode did not completely support concurrent locking. If a client started a concurrent transaction and then tried to perform a write operation to a record, the
Btrieve engine would return a status code 85 that indicated that the file was locked — even though a concurrent lock was being used.
132:, as versions of Btrieve until version 6.15 use a standard file format and, until Btrieve 6.0 was released, were completely backwards compatible. Btrieve 6.0 introduced new features and had to break compatibility with older versions of the software to implement more advanced features. The
326:. For instance, an ACS might allow the sort order to sort in both case-sensitive and case-insensitive order. Prior to version 6.0 only one ACS was able to be stored in the file, however after 6.0 was released more than one ACS page could be associated with a file at any one time.
334:
In version 6.0 and later files, more physical pages can exist than are actually used. This is because with shadow paging some pages in the system may not have an entry in the PAT. These pages are marked as "Extra" pages, and are used up before space for new pages is allocated.
428:(MEFS) mode. SEFS only allowed the clients that accessed that engine to alter the database, other clients that accessed a different engine could not gain access to the database. MEFS allows different clients running under different engines to access the database.
262:
The amount of logical records that can be stored in the PAT is determined by its page size. Each page pointer in versions 6.x and 7.x of the MKDE takes up 4 bytes of space, and the PAT header takes up 8 bytes, so the amount of logical pages in the PAT becomes:
298:
was used instead of pre-imaging, and it is still used to this day. Instead of copying the page into a temporary file, the next spare physical location in the database file was found and the page was written to this location. This page is called a
101:
has been designed with record management in mind. This means that
Btrieve only deals with the underlying record creation, data retrieval, record updating and data deletion primitives. Together with the
407:
method (this terminology started being used when version 6.0 was released). The linked duplicate method used a pair of record pointers in the index page itself to point to the head and tail of a
148:
Pervasive initially used the term "navigational database" to describe
Btrieve, but later changed this to "transactional database". The use of the term navigational database was unusual because a
307:
The change-over from pre-image paging to shadow-paging caused radical file format changes that broke compatibility between previous versions of
Btrieve and version 6.x of the product.
322:
is the assembly of written information into a standard order. In common usage, this is called alphabetisation, though collation is not limited to ordering letters of the
519:
278:
With the introduction of MKDE version 8, the size of the page header changed and so this formula no longer applies but the principle remains the same.
609:
537:
176:
from the interface that developers used. They separated the core database operations (like update, write and delete records) from the
Btrieve and
177:
51:
215:
The
Btrieve file format consists entirely of pages, which is the data that moves between memory and storage media when the engine performs an
528:
136:
likewise remained backwards compatible, with only one feature (split files to separate media) being dropped. At one point, Btrieve's former
304:
shadow page the PAT would not be updated and so the change would be dropped because the current and next entry was not updated in the PAT.
546:
368:
column of the database table. The arrows point from the index value to the rows that contains the value in the "Employee ID" column.
391:
that have those column values, which provides a quick way to find the rows within a table using the indexed column. B-trees are
184:
to use several methods of accessing the database simultaneously. For instance, an application may be created using the Btrieve
505:
420:
When Btrieve needed to do file sharing to gain access to records, two different types of file sharing modes could be used:
140:
Ron Harris stated that "The version 1.0 API is still supported in version 6.15, and we're going to keep it forever!".
590:
73:
44:
444:
locking; from 6.0 onward, records could be locked individually. Locking at the record (or page) level was known as
437:
555:
196:
primitives have been separated from these methods, both applications can use the MKDE to access the same data
360:
Btrieve uses indexes on certain columns to retrieve data in a speedy fashion. The structure at the top is a
192:
that needs to access the same data may use a totally different method, like using Scalable SQL. Because the
243:
The file control record (FCR) contains important information about Btrieve database files. It holds the
168:
The MKDE model allows for different database backends to be plugged into Pervasive's software product.
223:(FCR). The file had an index for searching that linked to physical pages. Beginning with version 6.0
193:
34:
172:
Starting with version 6.15, Pervasive started using a new modular method of separating the database
399:
Btrieve allows for duplicate key values in an index. Btrieve handles duplicate keys using either a
180:
modules. By separating the Micro-Kernel Database Engine (MKDE) from the other functions it allowed
38:
30:
129:
55:
149:
541:. Pervasive KnowledgeBase article (article ID: BTRTT-97070801). Retrieved December 12, 2004.
387:. The index maps each set of indexed column values to the set of unique identifiers for the
462:
189:
8:
392:
408:
94:
586:
440:
in the 6.x series. Before Btrieve 6.0 the engine could only do file level locking or
384:
173:
153:
381:
377:
118:
231:(pages at a fixed location in the file) on the disk through the use of a set of
388:
564:
603:
197:
318:(ACS) pages are pages that allow records to be sorted in a different order.
219:
operation. Versions prior to 6.0 merely used data pages, index pages and a
110:, Indexed Sequential Access Method, as its underlying storage mechanism.
204:
114:
181:
319:
244:
583:
Btrieve complete: a guide for developers and systems administrators
323:
90:
449:
write transaction by another process that had locked the record.
86:
373:
361:
356:
585:. Reading, Massachusetts: Addison-Wesley Publishing Company.
412:
This means that the key is retrieved via its position order.
164:
547:
Btrieve for Windows NT/Windows 95 Installation and Operation
122:
107:
216:
185:
137:
133:
227:
started to be used, which are pages that are mapped to
461:
Starting with version 6.15 of Btrieve, a new type of
310:
281:
152:uses "pointers" and "paths" to navigate among data
338:
556:btrieve database file access (PageSize detection)
529:Btrieve for DOS Installation and Operation manual
203:The Micro-Kernel Database Engine is unrelated to
103:
601:
43:but its sources remain unclear because it lacks
456:
159:
113:Btrieve is essentially a database that uses
250:
74:Learn how and when to remove this message
538:Status 96 from a NetWare NLM Application
506:Understanding Btrieve and Scaleable SQL4
355:
163:
610:Proprietary database management systems
143:
602:
565:btrieve recovery utility (open source)
238:
504:Dahunsi, Ayodele (January 1, 1998).
15:
575:
13:
311:Alternate Collating Sequence pages
14:
621:
282:Pre-image paging vs Shadow paging
20:
415:
364:data structure and indexes the
339:Variable-tail allocation tables
523:. Retrieved December 12, 2004.
483:
431:
346:variable-tail allocation table
329:
1:
520:Components of NetWare Btrieve
497:
457:System and user transactions
316:Alternate Collating Sequence
160:Micro-Kernel Database Engine
7:
544:Pervasive (November 1996).
469:, which was separated from
436:Btrieve was able to handle
351:
104:MicroKernel Database Engine
10:
626:
422:Single Engine File Sharing
207:operating system kernels.
426:Multi Engine File Sharing
294:Starting in version 6.0,
210:
562:dbcoretech (July 2010).
476:
465:was introduced called a
128:Btrieve is committed to
29:This article includes a
553:C Fiedler (July 2010).
438:concurrent transactions
268:Number of logical pages
99:architecture of Btrieve
58:more precise citations.
403:method, or by using a
369:
251:Page allocation tables
233:page allocation tables
169:
130:backward compatibility
359:
257:page allocation table
167:
150:navigational database
463:database transaction
393:tree data structures
144:Database terminology
405:repeating duplicate
286:Until version 6.0,
239:File control record
221:file control record
581:Kyle, Jim (1995).
535:Pervasive (1998).
526:Pervasive (1997) .
517:Novell (no date).
467:system transaction
409:doubly linked list
370:
170:
95:Pervasive Software
31:list of references
550:. Product manual.
532:. Product manual.
471:user transactions
424:(SEFS) mode, and
84:
83:
76:
617:
594:
579:
510:Clarion Magazine
491:
487:
401:linked duplicate
376:format to store
288:pre-image paging
79:
72:
68:
65:
59:
54:this article by
45:inline citations
24:
23:
16:
625:
624:
620:
619:
618:
616:
615:
614:
600:
599:
598:
597:
580:
576:
571:
500:
495:
494:
488:
484:
479:
459:
434:
418:
372:Btrieve uses a
354:
341:
332:
313:
284:
253:
241:
213:
162:
146:
80:
69:
63:
60:
49:
35:related reading
25:
21:
12:
11:
5:
623:
613:
612:
596:
595:
573:
572:
570:
569:
560:
551:
542:
533:
524:
514:
513:
501:
499:
496:
493:
492:
481:
480:
478:
475:
458:
455:
433:
430:
417:
414:
380:on particular
378:record indexes
353:
350:
340:
337:
331:
328:
312:
309:
283:
280:
276:
275:
252:
249:
240:
237:
229:physical pages
212:
209:
161:
158:
145:
142:
82:
81:
39:external links
28:
26:
19:
9:
6:
4:
3:
2:
622:
611:
608:
607:
605:
592:
591:0-201-48326-2
588:
584:
578:
574:
567:
566:
561:
558:
557:
552:
549:
548:
543:
540:
539:
534:
531:
530:
525:
522:
521:
516:
515:
511:
507:
503:
502:
486:
482:
474:
472:
468:
464:
454:
450:
447:
443:
439:
429:
427:
423:
413:
410:
406:
402:
397:
394:
390:
386:
383:
379:
375:
367:
363:
358:
349:
347:
336:
327:
325:
321:
317:
308:
305:
302:
297:
296:shadow paging
292:
289:
279:
273:
269:
266:
265:
264:
260:
258:
248:
246:
236:
234:
230:
226:
225:logical pages
222:
218:
208:
206:
201:
199:
195:
191:
187:
183:
179:
175:
166:
157:
155:
151:
141:
139:
135:
131:
126:
124:
120:
116:
111:
109:
105:
100:
96:
93:developed by
92:
88:
78:
75:
67:
64:December 2018
57:
53:
47:
46:
40:
36:
32:
27:
18:
17:
582:
577:
563:
554:
545:
536:
527:
518:
509:
485:
470:
466:
460:
451:
445:
441:
435:
425:
421:
419:
416:File sharing
404:
400:
398:
371:
365:
345:
342:
333:
315:
314:
306:
300:
295:
293:
287:
285:
277:
271:
267:
261:
256:
254:
242:
232:
228:
224:
220:
214:
202:
188:and another
178:Scalable SQL
171:
147:
127:
121:to organise
112:
98:
85:
70:
61:
50:Please help
42:
432:Concurrency
366:Employee ID
330:Extra pages
301:shadow page
205:microkernel
190:application
182:programmers
56:introducing
498:References
446:concurrent
442:exclusive
320:Collation
272:Page size
245:page size
604:Category
352:Indexing
324:alphabet
274:÷ 4) - 8
235:(PATs).
106:it uses
91:database
385:columns
348:(VAT).
174:backend
154:records
119:indexes
87:Btrieve
52:improve
589:
374:b-tree
362:b-tree
211:Paging
194:record
97:. The
477:Notes
382:table
89:is a
37:, or
587:ISBN
389:rows
198:file
123:data
117:and
115:keys
108:ISAM
270:= (
217:I/O
186:API
138:CEO
134:API
606::
508:.
255:A
200:.
41:,
33:,
593:.
568:.
559:.
512:.
77:)
71:(
66:)
62:(
48:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
