Bug 126355 - Can't correctly parse import numeric decimal position when pasting a table from Calc
Summary: Can't correctly parse import numeric decimal position when pasting a table fr...
Status: RESOLVED DUPLICATE of bug 123591
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-11 23:59 UTC by rich
Modified: 2019-07-13 18:45 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Calc sheet cells for import (54.40 KB, image/jpeg)
2019-07-12 23:10 UTC, rich
Details
Type formatting during import (56.97 KB, image/jpeg)
2019-07-12 23:11 UTC, rich
Details
Table1 results after import done (37.96 KB, image/jpeg)
2019-07-12 23:12 UTC, rich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rich 2019-07-11 23:59:11 UTC
After selecting and copying a range of cells in Calc, the paste function into a new table in Base does not correctly parse numeric fields which contain decimal points.  This happens no matter what type of "number" data type is specified for the target column in Base.  Changing the target field number of decimals creates some strange results in terms of placing the decimal in the result.  I tried this in OpenOffice 4.1.6 and it works perfectly.  I finally migrated my data using OO and will try to get going with LibreOffice on this database.  If I need to create screen shots showing this I can but it is trivial to reproduce from scratch.
Comment 1 Robert Großkopf 2019-07-12 18:22:43 UTC
(In reply to rich from comment #0)
> After selecting and copying a range of cells in Calc, the paste function
> into a new table in Base does not correctly parse numeric fields which
> contain decimal points.

Which internal database do you use? Firebird or HSQLDB?
Comment 2 rich 2019-07-12 20:56:18 UTC
I'm a new LO user so not sure which DB engine...but I believe it is Firebird.

FYI, I was downloading the local help file and noticed LO version 6.2.5 was available.  I downloaded and installed that version and the problem has gone away, at least I can't reproduce it  It was a definitely a problem with 6.2.4.2.  I guess you can close the bug report.  Thanks.

FYI and for grins, to reproduce, create a sheet with three "headings" in row 1, "Col 1", "Col 2" and Col 3".  In row 2 enter 123.4, 123.45, 123.456.  Select those cells and copy, then paste into the table area in Base.  Import all fields and change each to "Number" and decimal 1, 2 and 3.  Click create and examine the new table contents.
Comment 3 rich 2019-07-12 23:08:57 UTC
For what it's worth I recreated the 6.2.4.2 environment on a separate W10 workstation and duplicated the problem to be sure I wasn't going crazy.  I'm uploading three screen shots with:

1. Calc sheet cells for import (self explanatory)
2. Type formatting:  the settings and values I used for the three numbers import
3. Table1 results (self explanatory)

I'm doing this in case this problem has somehow gone dormant but is still present.
Comment 4 rich 2019-07-12 23:10:27 UTC
Created attachment 152745 [details]
Calc sheet cells for import
Comment 5 rich 2019-07-12 23:11:44 UTC
Created attachment 152746 [details]
Type formatting during import

Same entries for all except number of decimals.
Comment 6 rich 2019-07-12 23:12:29 UTC
Created attachment 152747 [details]
Table1 results after import done
Comment 7 rich 2019-07-12 23:13:54 UTC
I am going to upgrade my test environment to 6.2.5 and won't be able to do any more testing in 6.1.4.2.
Comment 8 Robert Großkopf 2019-07-13 18:45:37 UTC
Isn't this a duplicate of
bug 123591 or bug 126268 ?

There are some problems with numbers with decimal places, when importing from Calc or other databases to the internal Firebird database. This bug looks the same way like
https://bugs.documentfoundation.org/show_bug.cgi?id=126281 

I will close this one as a duplicate of bug 123591, which will be fixed in LO 6.3.0.2

*** This bug has been marked as a duplicate of bug 123591 ***