I am not sure about that, but up to my knowledge a
needs to be treated as having ZERO decimals
Note: Zero-decimals is the standard format for counters in DBase-files.
The counter is brooken and Calc is destroying data, when it is treated as STANDARD (and thusby falsy added a ,00)
Note: an Label,N,8,0 seems to work perfect, but thats not the case.
Kohei, what do you think, please?
I am going to put this on ther list of the most-annoying bugs
Still no chance to use DBF as data-exchange-files (in LO and OOO too),
as LO falsy justifies left-to-right and adds decimal delimiter in N0-fields,
which means dataloss. not really a regression, as it never worked (what a pitty).
Please attach a representative dbf document that you typically work with. Dbf has many variants. I just want to know which version we are dealing with here.
This cannot be a blocker for 3.4 since "this never worked" (as you say).
A good place to start researching on dbf file format.
There are several external links to (vary rare) dbf file format specification of some versions of dbf, but not all versions.
Created attachment 46879 [details]
N,19,0 becomes N,7,2
Did I mention, that this is funny arguing?
You need to have a DBF-application - reopen the wrong-formed DBF in OOO/LO
works fine However: still worthless in 3.4 Beta 5
Look at attached screencaptures:
zaehler,N,19,0 (that is correct) - becomes
Now the digits are justified correct (right to left) , but inserts a decimal+00
and changes the format
Fun: it shortens the fieldlength and makes it dynamic - in regard to the
longest number in that column. I do not know, whether this will have any effect
when reopen in real DBF-applications, lets see. that happens on decimals only,
not on text-fields.
Don't know whether my problem relates to this one, but I have .ods document opened with LO Calc, and when I am entering to a pre-print mode, trying to print it or export to PDF, then all zeros disappear. This looks like if we apply decimal format with no leading zeros to all cells where numbers reside. Switcing to text format of cells does not help.
I use LO 2.4.5
Don't know whether my problem relates to this one, but I have .ods document
opened with LO Calc, and when I am entering to a pre-print mode, trying to
print it or export to PDF, then all zeros disappear. This looks like if we
apply decimal format with no leading zeros to all cells where numbers reside.
Switcing to text format of cells does not help.
I use LO 2.4.5
Stop spamming bugzilla please. And this is not a user forum.
the same problem with version 3.6 (linux) 126.96.36.199 (windows)
dBase export filter seems to ignore numeric format header information e.g ?,N,0, or tries to optimize/modify format header.
this behavior is very bad.
if there is a header information available, then dbase export filter must use this information, without any changes.
Don't assign anything to me please.
Please do not change the version field as it indicates the earliest version where bug is present. Changed back to 3.3.0 value (as original is no more available).
Created attachment 102382 [details]
ZIP with DBFtest in different flavours (Original, LO-Changed and LO-manual-set)
for a reason i do not know, the last comment is not visible, so
a short repeat:
1. LO still does not detect "Fieldname,N,19,0" (similar to "integer" and used for counters) on opening dbf-file,
a construct like this will always be opened like "Fieldname,N,19,2" (decimal with two digits)
2. DBF-file will never be reused but always overwriten with a new DBF, but that is well formed accordingly to the header-settings
(This is better than in the past, when wrong formed records had been added to the file with the result of corrupting the DBF-File)
3. The settings in the header will be treated right, so manually set the header to "Fieldname,N,7,0" will save the file accordingly (works for dbf-reading applications). However, when reopening that file in LO, LO will treat this file wrong again (see item 1.)
Better than nothing, so at least the Help-File needs to contain an advice how DBF-numericals can be saved without decimals
LO 4.2.4 on Win7
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.0.5 or 5.1.0) https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
No, that issues seems to be solved - tested on LO 510 with clean dbf on import to calc and exported from calc to dbf, everything seems to work fine.
With final comment closing this as WFM. Thanks for the update!
*** Bug 47496 has been marked as a duplicate of this bug. ***