Memo File Format

[tom62]

I'm currently writing a file converter for DBase-3 files in Java, but I'm having a problem creating the memo file headers. According to techincal info that I found on the Internet (

http://www.clicketyclick.dk/databases/xbase/format/)

the first four bytes in the file header indicates the number of the next free 512 block in the memo file. When I open the memo file with a hex editor, I can't however not discover how this number is computed (or why it is needed in the first place).

Thanks in advance for your help.

 

[cricket]

Memos are held in a separate file with the extention .DBT and the same name as the database.

The database hold a pointer to the location of the related data in the DBT file. I assume the reason for the header indicating the next free block of 512 is for the next record to be added, and it is updated at each append or delete.

 

[LyndonOHRC]

That is true; the native db3 driver abandons the previous content and appends new content to the bottom of the dbt file when you are editing the memo. The number in the dbf file is the offset from zero (in the dbt) where the current memo content resides/begins. New 512 kb blocks in the dbt are used until the new content is written.

The only way, I know of with the native dBase III drivers, to pack the dbt is to copy the database using the "copy to" command. The copy command rebuilds the dbt leaving behind the abandoned content and rolling up all of the pointers. I mention this because I have used this behavior to inspect the dbf/dbt pair before and after editing the file to figure out how to read the files with modern tools. I just practiced with the files until I learned enough to write the iterations I needed for a project.

FYI – these, seemingly, crude tactics evolved because the typical client in those days were using the application on an 8088 processor and often the database resided on a 5 ¼ in floppy. The most important limiting factor back then was disk I/O. This strategy minimized the disk read/write load for an application. The theory was, minimize file I/O during daily use and pack the indices and memo files after hours as a maintenance routine.

Hope this is of some help.


Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[tom62]

Thanks for your help, but I was not looking for information about the database file but the memo file. I try to create a Db3 plus database with memo fields directly (with Java), without external libraries (BDE, ODBC, ADO, etc.) or native Db3 drivers, but don't understand what to write in the memo file header (.dbt).

The Db3 plus memo file (.dbt) contains 512k blocks of which the 1st block is the memo header. The header starts with a 4 binary digit code that indicates the next available 512K block "name?". What I would like to know is how this 4 binary digit code is calculated.

 

[LyndonOHRC]

tom62,

I think I found what you are looking for. I knew I had some dbase books with that information.

Two old, I'm sure out of print, dbase books I have should give you what you want. Here are the ISBN's

0-89588-301-5 & 0-89588-508-5

If you want I could scan the relevant pages for you. It's too much to type and you will need the tables.

Let know how I can best get the information to you.

Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[LyndonOHRC]

Here is more:

http://www.klaban.torun.pl/prog/pg2xbase/contrib/dbf-format.html

http://groups-beta.google.com/group/clipper2coldfusion?hl=en

Lyndon

---People Remember about 10% of what you say ---They never forget how you made them feel. Covey

 

[tom62]

Thank you very much for your support, Lyndon. I just found out the correct memo-file format myself, by looking at some java code snippets on

http://www.koders.com/.

The difficulty I had with the next 512k block value, was caused by fact that Dbase stores its integers in the DOS unsigned integer (int16) format, while Java uses the signed integer (int32) format.