DBF file format problem: DBFs created with Harbour cannot be read by Java application

[John Ward]

I am having a problem with the DBF files created by Harbour.

 

The DBFs are not readable by another (Java) application.

 

I am still tracing it down, but I believe it is because the field definitions written into the header is missing the "Displacement of field in record" data.  Harbour just puts "00" Hex in position 12-15.

 

The field definitions can be found here:

https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/st4a0s68(v=vs.80)?redirectedfrom=MSDN

and here:

https://www.whitetown.com/misc/dbf/

 

We have a work-around by re-using a DBF (previously created in Clipper 5.2) where we zap and re-populate, but new DBFs created with dbCreate() fail to be read.

But I would prefer to find a permanent solution, especially if we have to create a new DBFs that need to be read by Java. As it stands right now with our 64-bit workstations, we are out of luck (unless we install something like dosbox and create the DBF in 16-bit Clipper).

Anyone else have this issue, or know a work-around to make sure the DBF format is correct?

 

Sincerely,

 

John

[John Ward]

So I finally got a chance to dig into the Java code and it is not a Harbour issue. Apparently Clipper loosely followed the rules to define a field name with less than 10 characters and only padded with one null character instead of all nulls.

This caused the Java code to misread some DBF field names, as it added the random characters after the null character to the field name. This lead the developers to code reading the DBF file based on the incorrect field name. Because Harbour strictly follows the DBF header, the Harbour DBF files were failing to be read in the Java app.

So they will be fixing the Java code to read the Harbour generated DBF files using the proper field names.

John