Apache OpenOffice (AOO) Bugzilla – Issue 87325
Export/Import .dbf fails - integrated
Last modified: 2013-08-07 15:15:24 UTC
1) Open attached test-dbf.ods file. 2) Save as test-dbf.dbf. 3) DBase export: Select Unicode (UTF-8). 4) It displays this message Error saving the document test-dbf: Connection to the file could not be established. 5) close test-dbf.ods 6) open test-dbf.dbf 7) Import DBase files: Select Unicode (UTF-8) 8) Notice the three cells have changed from (10 : 10 : 10) to weird stuff (N1,N,5,2 : N2,N,5,2 : N3,N,5,2) I have attached both files.
Created attachment 52240 [details] original ods file exhibiting issue
Created attachment 52241 [details] resulting dbf file exported
Tried this using 2.4 RC6 under Win XP - same problem. Tried again using 2.3.1 under Win XP - no problem
well, UTF-8 should not be an option for DBase-Export/Import - that sounds senseless to me Martin
From what I recall I tried some of the other options as well and they didn't work either. It wasn't just UTF-8, I just used that as example so I could exact steps to reproduce the issue.
With respect to other comments, if it only works for a very limited subset of language settings then it should be reduced to only allow those, so it is still buggy regardless.
at cheney I have a question, please: Are dealing with 32-bit-character-codes (UTF) - also in other languages - or are you striktly using 16-bit characters This is, because DBASE-files should only work with 16-bit-CodePages, and i just opened a wellformed DBF - exported it with "Save as ..." - and reopend it - and all works fine (in here with CP 437) please check rgds Martin
mhatheoo, It doesn't work for me for any format I have selected so far (many of them not just UTF-8). I am from the USA so we normally just use 8bit width characters and don't even really have need for 16bit characters here. I only used the UTF-8 option in the walk-through to give a reproducible example. It always displays weird 'N' stuff when I try to reopen it using the same format I saved out as. I even selected the 'Western Europe (DOS/OS2-437/US)' which I think is the codepage 437 you were referring to and it didn't work either. If some of the very many options it lets you save in for DBF format aren't valid then those should be removed, but so far I haven't found any of them to actually work at all.
I had the same problem on WinXP OpenOffice.org 2.4.0. When I change 5 to 6 by hands in all handles of fields (N1, N2 and N3) .dbf file was saved OK Was N1,N,5,2 must by N1,N,6,2 and so on. I think, if you will input negative value (-10), export will work OK :-)
Folks, the "weird stuff" (N1,N,5,2) you see in the first row after having opened a dBase file is the field structure. This is on purpose to make sure that when saving the file the identical structure is used, since other applications may depend on the exact structure. The sequence is fieldname,fieldtype,length,decimals. Seeing only that and no data is the result of the error that occurred during saving, apparently only the dBase header can be written and the database engine after that dislikes to write the file. The assumptions about character sets are not true. It seems that writing 2 digit integers to fieldwidth 5 with 2 decimals for some unknown reason is rejected by the database engine. Changing width to one more than is needed works around. @oj: Ocke, anything known about that?
Hi, when you try to save as dbf I noticed that a SQLException is thrown with this statement "The "N1" column has been defined as a "Decimal" type, the max. length is 3 characters (with 2 decimal places). The specified value is longer than the number of digits allowed." So you have to have in mind that N,5,2 means that can the value can be 5 characters long. 2 characters are reserved for the decimal places and 1 character for the sign (+/-). In other words only values from (+,-)(0..9).(xx) can be saved correctly.
Ocke, this is broken. It worked for years up to OOo2.3.1 that automatic determination of the field width does not have to take a hypothetical sign character into account if there wasn't any. I also don't see why one would have to waste an extra character for a sign if there are no signed values. The dBase specification IMHO doesn't require it, and we wouldn't be able to save in the identical structure once loaded if a file had numeric fields filled with positive values up to the field width. Please fix. Thanks Eike
*** Issue 87972 has been marked as a duplicate of this issue. ***
*** Issue 88061 has been marked as a duplicate of this issue. ***
*** Issue 88139 has been marked as a duplicate of this issue. ***
Same behaviour on windows xp; reverting to OO 2.3 fixes the problem. error message was unable to access the file.
Just to add to this; from a standard Calc file - File|Save As|dBase (.dbf) also does not work in linux OOo3.0devM7 (buildid=300m7(Build:9293)) and results in: Error saving the document <document name>: Connection to the file could not be established. It does not seem to matter which character set is used.
Happens on Windows too.
set target to 2.1.4
Fixed in cws dba241b
Thanks a lot!
Please verify. Thanks.
Has this been fixed in 3.0 as well?
Yes. It will be fixed for 3.0 as well.
verified in cws dba241b
set target to 3.0 to get this issue into 3.0 Beta. Then back to target 2.4.1 to get it also into 2.4.1
added "approved" to the title, because it will be easier to work with the 2.4.1 meta issue during release status meetings.
added "integrated" to the title
*** Issue 89094 has been marked as a duplicate of this issue. ***
=>eike I just read your comment regarding the point, that you think the coding of characters is not important (post. 4.Apr.) Thats not right. DBase can deal with fields of fixed length only - this is true for text aswell as numbers, as numbers are not encoded in DBase but stored in digits. By that, the possibility for save DBase with characters longer than one byte should be disabled. Ofcorse that will be no problem in US, but in all other countries will be - just as ccheney wrote on 2.Apr. btw: for the number-fields I thought, the leading figures (incl. a neg.sign in case - no positiv), and the decimal-dot (if any) and the tailing decimals (if any), all together will be given 15 characters space, filled from the right, the "length"- parameter in not seriously used, it just must fit into that. I am courious about 2.4.1 Martin
In scalc 3.0.0 this bug reappears!
verifayed at master version OOo 3.1 - the error message dos not appear at the export but when opening the *.dbf file that was exported the data is shown like in the exampele: (N1,N,5,2 : N2,N,5,2 : N3,N,5,2) windows vista
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues