Btrieve file index metadata

[thx1138v2]

With the help of Jim Kyle's information and articles published by dbcoretech I have been able to locate the file metadata. I have pretty much figured out the index metadata but am stumped on one item: the key segment field starting position in v6+ files.

I am able to find the key segment definitions using the KAT info in the FCR but the starting position of the fields in each key segment definition is different than the data dictionaries and this offset varies. For example the data dictionary might define a field starting at record offset 0 for a length of 4 bytes that is type 0 but in the index metadata in the file the offset will be 2 for a v6 file or 10 in a v7 or v8 file.

I'm assuming the first 2 bytes are for the PageId that went into use in v6.0 but can't really identify how the other 8 bytes are used in the later files. It appears to have something to do with duplicate pointers because all of my files that have the larger offset have duplicates. But not all files that have duplicates have the larger offset.

It appears that the v7.0 files hold this offset at 0xF2 or maybe 0xFE in the active FCR. That area is identified as vacant in the v5 and v6 FCR structures I obtained from the internet and the 0xF2 and 0xFE locations are not consistent in v8. In v8, the location of the additional offset seems to be at 0x0176. Although this works with the data files I have, it is just a guess and I'm not particularly comfortable with it.

Everything I've found on the internet deals with recovering data from Btrieve files but does so by reading the data pages. I haven't found anything that deals with the indexes.

Does anyone know of any info available via the web about the index metadata or if this offset is a calculated offset (i.e. not stored in the FCR) and, if so, how to calculate it?

Any help will be greatly appreciated. Thanks in advance.

 

[JimKyle]

Those additional 8 bytes offset in Version 7 and 8 files (and later) are the hidden "system id" timestamp, I believe. Your presumption for the first 2 bytes is almost correct; it's a reference count that serves as a deleted-record flag also. The FCR offset is the starting point for any calculations, and is an offset within the record, not within the page. The catch is that, as you have discovered, not all bytes within the physical record area are considered to be part of the record itself.

I'm curious why you need index metadata, though. There's a program in "Btrieve Complete" that will dump the index structures, but I've never found it to actually be useful -- unlike the data dump routines.

 

[thx1138v2]

I have a client who is still using a third paty Btrieve application for which I wrote some ADO Btrieve queries in an Excel macro. It worked fine for a couple of years and, out of the blue, started reporting bad numbers.

I chased my tail for a couple of days trying to locate the problem which actually turned out to be incorrect data dictionaries. Someone copied an old, old version of the data dictionaries into the data folder.

I can't prevent that from happening again so I thought I would write a VBA routine to do the same thing as the PCC Check Database and bring up a notification if discrepancies were found and cancel the report instead of producing bad numbers.

I went a bit overboard in developing the PCC Check Database routine and thus got into the index metadata issue.

All I really needed to do was check the DDF's for the presence and offsets of six particular fields to validate the DDF's are the ones needed.

Thanks for your reply.