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).

Martin

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.

http://en.wikipedia.org/wiki/DBase#File_formats

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
zaehler,N,7,2 (wow!)

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.

Martin

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) 4.0.4.2 (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

mh

LO 4.2.4 on Win7

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.
thanks.
mh

With final comment closing this as WFM. Thanks for the update!

*** Bug 47496 has been marked as a duplicate of this bug. ***