Apache OpenOffice (AOO) Bugzilla – Issue 44116
Displaying non-accurate width of numeric field
Last modified: 2017-05-20 11:13:06 UTC
The outcome of Save As dBase command still cannot produce the accurate width in displaying numeric field. The displaying field width will be abnormally varying to fit individual numeric length. Though it is readable by other xBase applications, but the displaying result on browse screen in text-mode, such as dBASE 4 or FoxPro/DOS or any DOS based applications, is very annoying.
Hi, please attach a document showing your problem and/or describe step by step how to reproduce it. Frank
I tried creating 2 simple dbf files (with just 2 columns of decimal numbers), 1 using OOo 1.9.122 and 1 using Excel 2002, both under WinXP Pro SP2. The resulting dbf files seem equal. I tried opening both files, each one with both programs, and I noticed a very little difference only in the first line of the list of numbers. The dbf created by OOo seems completely correct, even if opened with Excel; the dbf created with MS-Excel looses the first value of each column, even if opened with OOo or MS Access 2002. I didn't try anything else, but it seems to me the issue has been solved.
The problems affect only in text mode application, such as dBASE, DBV, not in any of GUI software. Anyway, OOo1.9.122 already resolved the field name contained "0" (zero character) issue, while OOo1.1.5 still cannot handle the field name containg the "0" character properly. However, the appearance of output result from OOo1.9.122 seems to be fixed for FoxPro/DOS but more terribly ugly on dBASE/DOS browse screen. Maybe all the mentioned issue is concern only some legacy software that should be extinctive nowadays. But the curious point is that what had happened in this unfulfilled features while MS Excel can do it smarter in exchanging the files among various applications.
Hi, as I've said before, give us a detailed description of the problem. With the given information we don't know how to reproduce it. Maybe a screenshot or two would help. Frank
Created attachment 28642 [details] screen shot of the mentioned problem
Created attachment 28657 [details] Test dBase file saved by Excel
Created attachment 28658 [details] Got an other PDF by Mail containing some more information
Hi Frank, Problem seems to be located in the export to DBF. Currently we export the value and fill the remaining places with $00, according to Eike it should be the other way round. Spaces in front of the values. Please have a look and discuss with Eike. Frank
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please re-test with one of the latest versions of OOo - the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be closed or progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further : http://www.openoffice.org/issues/query.cgi Regards, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~
Open Office Calc save numeric value in numeric column as text representation and add null chars right for column with. Bat other applications save value as text and space chars left for column with. For example: Format: N, 3, 0 Value: 1 Calc saved value (hex): 31 00 00 Other App saved value (hex): 20 20 31 This inaccuracy does not affect the format of the readers implemented in C or C + + but can break the implementation in other languages (Python, Ruby, Haskell)
Created attachment 68031 [details] dbf created by OOo Calc
Created attachment 68032 [details] OOo Calc dbf edit in dbu.exe (clipper dbf util)
See the patch at https://bugs.freedesktop.org/show_bug.cgi?id=30504
Reset assigne to the default "issues@openoffice.apache.org".