Apache OpenOffice (AOO) Bugzilla – Issue 8857
Bad DBF file identification?
Last modified: 2008-06-17 13:50:53 UTC
Hi, the attached file is correct DBF file (OOo can Open it as a Data Source). Although when this file is given on the command line: soffice bad.dbf or it is opened via Ctrl+O, it is opened in the Writer. The same applies for 1.0.1 and als for 643.
Created attachment 3434 [details] Misidentified DBF file
Pavel, thank you for using and supporting OOo. How was bad.dbf created? Was is created using DBase? If so which version?
On Win NT 4.0 SP6a, OOo 643, the Data Source component does not see any tables in the attached dbf file.
I can open the file in 643 - see attachment. It is correct. I do not know who created it though. dbview shows the same content as OOo.
Created attachment 3438 [details] Snapshot of OOo 643 opening bad.dbf
Which language of OOo are you using?
This is OOo in Czech language (not part of CVS yet).
TM->MSC: Seems to be more a database problem in the Czech version than a framework bug to me. Please have a look, thanks !
Hi, reassign to the spreadsheet team becasue this file is loaded correct in the database component , but it doesn't load correct in the spreadsheet component. Marc->Oliver: Just try to load the attachment bad.dbf in calc. Impossible. Bye Marc
Any new info on this Issue?
Hi Eike, could you please have a look why Calc can't load the file while the database can access it.
Similar to issue 4991: 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 0x0483. The last byte of the header has to be a 0x0d, which isn't the case here. The 0x0d is at offset 0x0480 instead, and two more bytes follow to pad the header. Calc does check for the presence of the 0x0d at the given offset, and if not found refuses to load the file. The last instance in the chain is the Writer module, which then loads the file as text. The database module however has a somewhat more relaxed check and doesn't complain, so the file is availabel as data source. I'd suggest to fix the tool that produces such erroneous files.
close wontfix
change subcomponent to 'none'
This issue is also ms_interoperability : My uncle uses an "export to MS Excel" function of the proprietary program "CC-WinFaktura" which is part of "CC-WinClub&Office". It produces a *.DBF file and opens it, which opens openoffice.org, but then openoffice.org fails to read the *.DBF-file in calc and only reads it as ASCII in writer. I will attach ccwin.dbf, an anonymized version of such an exported file. It has its header length wrong: It has the value 0x562 at offset 8. If I modify this to 0x561 (the location of 0xD + 1), it opens fine in openoffice.org. Other programs, like Microsoft Excel, or dbf-0.8.3 (http://developer.berlios.de/project/ showfiles.php?group_id=1219) have no problems with the unmodified version. I propose that this issue is re-opened, so that in the future openoffice.org reads *.DBF files even if they contain an invalid header length.
Created attachment 32779 [details] ccwin.dbf.zip, a (zipped) dBase III file created with CC-WinFaktura, which openoffice.org can't read
Martin, This file is even worse than the "usual" violation of file format specification (0x00 pad byte) mentioned above: it includes a trailing ^Z / 0x1a byte in the header length instead. OOo2.0.x opens the file in Calc after the "dBASE" filter was selected. Btw, changing the header length from 0x0562 to 0x0561 may make the file load, but results in corrupted data since the data is shifted by one byte through all fields. This is also not an interoperability issue, MS-Excel 2003 opens the file but doesn't load any data, only the header definitions, maybe because the ^Z is interpreted as the DOS end-of-stream mark. I strongly suggest to get the file creation fixed in the CC-WinFaktura application. Eike
For the records: also this one was fixed with the patch from issue 88577.