Apache OpenOffice (AOO) Bugzilla – Issue 96191
.dbf export fails on N,x,0 fields
Last modified: 2013-08-07 15:14:39 UTC
1. Download and open attached tst.ods OR create new spreadsheet and set A1 to "fld,n,4,0", A2 to "99", A3 to "-99" without quotes. 2. Select from menu File / Save as ..., select file name tst, file type dBASE (.dbf) press Save button, accept warning about format (if occured), accept encoding (doesn't matter). Ok. 3. Set A2 to "9999", A3 to "-999" (without quotes) both or any and repeat step 2. Message box "Error saving the document tst: Connection to the file could not be established." appears. NOTE: After this tst.dbf locked, it's another bug, so change name of dbf when save as .dbf on every another try. Expected behavior: in step 3 file saved without error. Explanation: .dbf field of type N,x,0 can contain numbers from -9((x-1) times) to 9(x times). For ex. N,4,0 can contain numbers from range -999..9999. In other words, dbf integer numeric field with length x can contain integer numbers of length is x, where lenghth is: - number of significant digits for positive numbers - number of significant digits minus 1 for negative numbers. OOo mistakenly believed that .dbf field of type N,x,0 can contain (x-2) significant digits regardless to number sign. So, for .dbf field fld,N,len,0 range of acceptable value is min = - 10^(len - 1) + 1 max = 10^(len) - 1 For ex. fld1,N,5,0: min = -10^(5-1)+1 = -10^4+1 = -10000+1 = -9999 max = 10^(5)-1 = 10^5-1 = 100000-1 = 99999 ps. Sorry for my poor English.
Created attachment 57977 [details] test file
OOo 2.4.2 has the same behavior.
Confirmed in OOo 3.0 on Linux
@oj: Is this a reincarnation of the infamous sql-driver-wants-larger-field-width-than-dbase-requires issue? I didn't find its number.. feel free to close as duplicate if appropriate.
http://www.openoffice.org/issues/show_bug.cgi?id=87325 http://www.openoffice.org/issues/show_bug.cgi?id=94644
This is similar to i94644 but not the same. This is about field,N,x,_0_. For field,N,len,dec need to reduce the length of an integer part of a further 1 (for decimal separator).
Hmm, if you use A1 "fld,n,8,2" (-9999.99..99999.99) and - A2 "99999.99" you doesn't get error, field in .dbf will be fld,N,8,2 - A2 "999999.99" you doesn't get error, field in .dbf will be fld,N,9,2 i.e. field capacity silently adjusted for data size. If you use A1 "fld,n,?,0" or "fld,n,?,1" field capacity doesn't silently adjusted for data size and you get error. Is this behavior by design or as happened?
add CC
Fixed in cws dba31f - the value will be checked - the field description will not be changed when defined - the error message from the dbase driver will be shown, which should be more informational
Ocke, thanks a ton for quick fix. Could you, please, also take a look at dbf-related issues http://www.openoffice.org/issues/show_bug.cgi?id=94644 http://qa.openoffice.org/issues/show_bug.cgi?id=96169 ? Thanks in advance. WBR, KP.
Please verify. Thanks.
verified in CWS dba31f find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba31f
Checked in OOO310m9 (Build 9396), Windows XP. Problem still exist. Should be fixed.
Verified in OOo310m9 on WinXP and Fedora. No errors at step3 Closing Li Meiying
whoever closed this issue, it is nonsens a field N,0 can be used in OOO only, not in any DBase-related application, as the number is justified from left to right, whereas DBase needs to justify right to left, and opening such files will result in error (dataloss!). BTW: look at the attached screencapture the DBF-content is displayed correct (no digits right of any delimiter)(this is a feature of the ooo-displaymethod "standard"), but the format-settings in the top-line are different from what is displayed, a cann't be (and where the 2 digits is part of the nonsens) Is it too complicate to have top-line-format = cell-format = displayed format? reopen please Martin
Created attachment 76198 [details] content displayed different from given formatting