Apache OpenOffice (AOO) Bugzilla – Issue 4991
Foxpro 2.6 .dbf file will not open in CALC
Last modified: 2003-09-08 16:55:29 UTC
I work with a database that produces .dbf files in Foxpro 2.6 format. When I try to open them in CALC, the file opens instead as a text file in WRITER. The same file will open flawlessly in Excel or 1-2-3. If I open it in Excel and resave it from Excel in .dbf format, it will open correctlly in CALC. If I could see where or how to attach a file, I would attach a sample Foxpro 2.6 format .dbf file for your use.
Created attachment 1683 [details] Foxpro 2.6 format .dbf file that won't open in CALC
I'll have a look, Peter
Hi, there's something strange about this file. vi freezes. Gnumeric crashes opening it. Kspread wouldn't even find it. Starting it from a terminal using 'kspread .../Supplies.dbf' crashes kspread too. OOo opens it always in writer no matter which filter I select. Only Excel hasn't any sign of problems. @ Eike: Some strange characters at the beginning of the file. Is this a valid dbf file at all? Peter
The file was produced using Alpha Five version 4.5 for Windows, a relational end-user database. The folks at Alpha Five have built their program using the CodeBase xBase engine from Sequiter Software, a product utilized by a variety of programmers looking to add database functionality to their software. It is presumably Foxbase 2.6 compatible, but I don't know enough about file formats to verify that. The Sequiter folks may be able to provide more information. Their web site is www.codebase.com. Thank you for your interest and assistance.
@Peter: Don't know which rotten vi you're using, but vim had no problem, of course ;-) @all: The format of this file doesn't follow the dBase specifications exactly and differs in one aspect: at file offset 8 (zero based) there is a 16-bit little-endian value telling the overall length of the header, here 162. The last byte of the header (in this case at offset 161) has to be a 0x0d, which isn't the case here. The 0x0d is at offset 160 instead, and another 0-byte follows to pad the header. If the two values are exchanged (0-byte at offset 160, 0x0d at offset 161), then the file can be loaded. Excel seems to ignore all sanity checks (as usual), but Calc checks for the presence of the 0x0d at the end of the header. @Paul: If you want your files to get loaded I suggest you contact the folks who are responsible for the product you're using to write proper file formats. Otherwise you'd had to use a utility that checks for the header format described above and corrects it if necessary.
closing
closing I said ...