Apache OpenOffice (AOO) Bugzilla – Issue 9581
dbf files are opened in the wp instead of sc
Last modified: 2013-08-07 15:15:18 UTC
dbf files are opened in the wp instead of sc even if you choose the dbase file type in the spreadsheet section of the "Files of type".
*** Issue 9690 has been marked as a duplicate of this issue. ***
Checked with OOo1.1rc2 and can not reproduce. So set to worksforme. Frank
closed worksforme
I've tried with all the 1.1RC and I still have the problem.
Hi, I'm still not able to reproduce what you're facing. Please attach a file which produce this behaviour. Don't know from there you've got the RC4, as this is not publicly available, I assume you've build it by yourself. Maybe you got a problem in this process. Frank
Created attachment 9081 [details] A file to test dbf import
Hi Frank, I got 1.1RC4 from http://gd.tuwien.ac.at/office/openoffice/stable/1.1rc4/OOo_1.1rc4_Win32Intel_install.zip Friday Sep/5 at 8.00pm. I simply did a standard setup, I cannot build it by myself. Lorenzo
Hi Lorenzo, this is not a bug from OOo but one from the developers of your database software. They do not follow the file format specification for dbase files. The header of an dbf file has to end with an CR ($od). If you have a look at your testfile (with an hex editor) you will find at offset hex 80 an od. But it should be in hex 81. Try it by changing the values. Another community memeber has discovered this before and filed Issue 4991 on it. Normaly I have to close it as double. After a talk with Eike we decided to handle this as RFE for checking on wrong position of $od. As workaround : Just go to Tools - Data Sources... and add the file as new datasource. After that press F4. You get the database beamer. Best regards Frank PS It seems that our proxy had a problem to get the correct pages. Now I've got the RC4 from the download site.
Frank, you are right !!! The dbf file is created with CA Clipper 5.3b. I've opened it with MS Foxpro 2.5 and I "copy to" another dbf and OO1.1RC4 opens it. The main difference I can see with hexview is that after the 80h 0D there is a 00. This means that the Clipper DBF is 1 byte larger than the FoxPro DBF. MS Foxpro gives no errors working with Clipper dbfs. Even StarOffice 5.2 works and also Clipper opens the "fixed" dbf without any warning. It seems that this "difference" has always been "managed" in some way. Regards. Lorenzo
Lorenzo, They all "manage" it by ignoring specifications. Maybe just because one main player kept spitting out those broken files.. Ok, since this is the I-dont-know-how-many-th .dbf file produced by some rotten software that doesn't follow the specification, I'll lose the checking a little bit for just those applications that don't seem to know about endianess or otherwise got the specs wrong and effectively pad the header with a trailing 0x00 after the 0x0d to reach an even boundary. At least those files made up the vast majority of issues we got reported, and by doing another check for 0x0d 0x00 at the header's tail instead of just a 0x0d we'd catch most files out in the wild.
Frank, a collegue pointed me to this link: http://www.fship.com/ftp/docutxt/dbfspecs.txt Lorenzo
According to the roadmap of OpenOffice.org 1.1 (http://tools.openoffice.org/releases/Openoffice_org_1_x.html) this issue has been scheduled for 1.1.2.
*** Issue 24843 has been marked as a duplicate of this issue. ***
*** Issue 24953 has been marked as a duplicate of this issue. ***
DR: fix reviewed
Fixed on branch cws_srx645_pp3calc: sc/source/ui/app/sclib.cxx 1.25.206.1
reassigned to qa
reset resolution to fixed
verified in internal build cws_pp3calc
Found integrated on Windows, Linux and Solaris