You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2015/07/16 12:35:52 UTC

[Issue 126404] New: Lost precision when copying table data

https://bz.apache.org/ooo/show_bug.cgi?id=126404

          Issue ID: 126404
        Issue Type: DEFECT
           Summary: Lost precision when copying table data
           Product: Base
           Version: 4.1.1
          Hardware: All
                OS: Windows 7
            Status: UNCONFIRMED
          Severity: normal
          Priority: P5
         Component: code
          Assignee: issues@openoffice.apache.org
          Reporter: larsj@sund.ku.dk

Created attachment 84825
  --> https://bz.apache.org/ooo/attachment.cgi?id=84825&action=edit
Sample database with high-precision data

When copying data from a table (or query) in Base, the data is copied "as
shown" which leads to loss of precision. I would expect that copying a table
from Base to Calc would preserve full precision, but this is not the case.

Example: The attached sample database contains a table with the following data:

MyTimestamp            MyDouble
01-01-2015 00:00:01    1.2345
01-01-2015 00:00:15    3.1415

However, when the table is opened then the times is only shown the the level of
minutes, and the numbers are rounded to two decimal places:

01-01-15 00:00         1.23
01-01-15 00:00         3.14

Showing it like this is not an error, but when I copy the data then data are
only copied to this precision. This is the case whether I copy the whole table,
or open the table and choose all data. Thus, precision is SILENTLY lost in the
copying process. I learned this only after loosing data in a copy.

(Full precision is kept if database is registered and a connection made to the
data from Calc.)

Lars J

-- 
You are receiving this mail because:
You are the assignee for the issue.

[Issue 126404] Lost precision when copying table data

Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126404

mroe <mr...@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOT_AN_ISSUE

--- Comment #1 from mroe <mr...@gmx.net> ---
I cannot confirm your observation. Maybe you have simply to change the number
format in calc? If this is not the case please provide a step-by-step
description how to reproduce the described behaviour.

-- 
You are receiving this mail because:
You are the assignee for the issue.

[Issue 126404] Lost precision when copying table data

Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126404

--- Comment #3 from mroe <mr...@gmx.net> ---
Hello Lars!

Now I can follow you, but in my opinion it is not a bug - it works as designed.
I'm not a AOO developer but I can imagine that it will result in big trouble if
a huge database table is copied into the clipboard.

Compare Paste Special… in Base and in Calc if you copied a database table into
the clipboard.

Base:
Formatted text (RTF)
HTML (HyperText Markup Language)
Data source table

Calc:
Formatted text (RTF)
HTML (HyperText Markup Language)


HTML and Text have no option to format a full precision value. And a HTML table
with full precision nobody want to have.

Data source table is IMHO only a link to the source not the data itself.

But you can simply copy the values without using the clipboard.

Open the base table and a calc spreadsheet. Select the desired rows in the
table and drag them with the mouse to the calc document.

-- 
You are receiving this mail because:
You are the assignee for the issue.

[Issue 126404] Lost precision when copying table data

Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126404

Lars Jødal <la...@sund.ku.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #84825|0                           |1
        is obsolete|                            |

--- Comment #2 from Lars Jødal <la...@sund.ku.dk> ---
Created attachment 84826
  --> https://bz.apache.org/ooo/attachment.cgi?id=84826&action=edit
Sample database, second go

You are right, surprisingly the problem cannot be seen with the sample base I
posted. Before posting, I tried changing the format for showing the data and
apparently succeeded in circumventing the problem (at least after saving).

Still, the basic problem is there. I have attached a new sample database with
the same data. Only this time I have not changed the default formatting:

TIMESTAMP: Format 00:00:00 00:00
Double: Format "Standard"

To see the problem I do this:
1. Open the database (sample2.odb)
2. Choose table view, rightclick on "Table1", and choose "Copy"
3. Open a new Calc spreadsheet
4. Paste the contents of the clipboard

Both time values are pasted as 01-01-15 00:00:00 (seconds not shown by
default), and the number values are pasted with only two digits.

AFTER having confirmed this behaviour, try changing the column format to verify
that there was actually more precision. (It would seem that if you THEN copy,
the precision will follow what is now shown.)

By the way: Going to the table and editing the data, I can neither see the full
precision by default, which could lead to precision loss in editing. A new
issue, or a second angle of the same?

Lars J

-- 
You are receiving this mail because:
You are the assignee for the issue.

[Issue 126404] Lost precision when copying table data

Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126404

--- Comment #4 from Lars Jødal <la...@sund.ku.dk> ---
Thanks, copying by selection and dragging gives the full precision.
I still thinks the behaviour is somewhat misleading, since it does not tell
that precision is lost. 

Replacing the standard "copy" (as shown) with two choices "copy as shown" and
"copy with full precision" would make things more clear. But I take your point
that it is not a bug, so instead of continuing here I will open a new Request
for Enhancement with that suggestion. Thanks for the comments.

Best regards,
Lars J

-- 
You are receiving this mail because:
You are the assignee for the issue.