Bug 133611 - Data loss in tables when opening odt file (libreoffice writer document) (STR see comment 5)
Summary: Data loss in tables when opening odt file (libreoffice writer document) (STR ...
Status: RESOLVED DUPLICATE of bug 131025
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: dataLoss, possibleRegression
Depends on:
Blocks: Writer-Tables-Style
  Show dependency treegraph
 
Reported: 2020-06-02 16:53 UTC by Richard Thier
Modified: 2021-10-29 14:41 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (8.56 KB, application/vnd.oasis.opendocument.text)
2020-06-02 17:12 UTC, Telesto
Details
What I see and what I should see (69.36 KB, image/png)
2020-06-02 17:19 UTC, Richard Thier
Details
Screencast (505.18 KB, video/mp4)
2020-06-11 14:41 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Thier 2020-06-02 16:53:20 UTC
Description:
I get heavy data loss in my tables when I am loading the file I have saved yesterday.

The tables I use are using the default table styles, but I do add some styling.

There is a not completely random data loss, where text is exchanged with "0" if I save the document and reload it later.

This is a heavy problem, because the tables in this document are actually for a business analysis for the software that I am writing / proposing so data loss makes me need to use some other tool for the moment while I finish this.



Steps to Reproduce:
It always happen in case of my document:

1. Just write the text in the fields of the document
2. Then save it and exit the app (can be seperately)
3. Then load the file and see some of the fields in tables are changed to "0"

I tried to 

Actual Results:
Some fields in tables are showing "0" instead of what I wrote in there.

All other things seems to be unaffected and show good data.

Also I saw that outlook.com (where I send these through) still see the original data so I think they are saved into the file if it can still see it in the online preview window.

Expected Results:
I expect the data to be there as I wrote it, instead of data loss on loading :-)


Reproducible: Sometimes


User Profile Reset: Yes



Additional Info:
I tried this on two seperate machines. Both of them run Linux and has:

LibreOffice 6.4.3.2 40(Build:2)

So this happens always for my document, but not always generally. I also tried to remove all other parts of the document and just keep the table - but then I can save it for some reason...

Also If I continue writing the document I saw that not always the same fields get erased...

I think something nasty is going on, but surely with tables.

As you see that some other apps still see the "lost data" I expect this to be a loading issue and not a saving issue, but I understand these are complicated files so it might a saving issue that some other applications do not really get crippled by - just I find it less likely.

I cannot share this document right now, because it has confidential data like company tax numbers and such, but it is always reproducible on my machine.

(I answered yes to "did you try resetting user profile, because one of the machines I try this on is practically a completely new installation - but I did not directly try that. I think it is the same hopefully)
Comment 1 Richard Thier 2020-06-02 16:54:26 UTC
This is for libreoffice writer and I talk about tables that are in the writer document - just for clarification.
Comment 2 Richard Thier 2020-06-02 17:00:48 UTC
Onlyoffice also opens the file - albeit it shows other issues around headers not numbered properly.

So the data I have entered is somewhere in the odt file, but for some reason cannot show up in libreoffice.

I must add that I have created this file libreoffice and not any other office suite - just I am now finding alternatives so that I can get my data back as a temporal workaround.
Comment 3 Richard Thier 2020-06-02 17:04:56 UTC
Okay... I grew unsure about how the original version of this file came to exist and it might be that I saved some word file as odt once in the lifetime, but it was too long ago for me to remember as I always used to fill this template on linux, just usually not using many tables.

I think in far-far past once the file was created from changing a docx, but as I told you all I am not sure. I can imagine that crippling functions like this maybe.

But I am sure it was libreoffice that created the odt file version. That is I am sure.
Comment 4 Richard Thier 2020-06-02 17:12:25 UTC
I practically deleted everything except tables in an other app where the data loss was not visible and saved it as a seperate file. That file I can open in libreoffice without data loss.

I will try to put together my data with my original document using this workaround and then try to save it to some other format. Either docx or something.

I expect it to work more or less as a workaround. Just writing this in case anyone else has similar issues and need quick workaround.
Comment 5 Telesto 2020-06-02 17:12:49 UTC
Created attachment 161537 [details]
Example file

1. Open the attached file
2. Select the table
3. Apply Sidebar -> Table Styles -> Box List Green
4. Save & Reload -> Part of the content replaced by 0
Comment 6 Richard Thier 2020-06-02 17:19:13 UTC
Created attachment 161539 [details]
What I see and what I should see

I went and searched for an affected table that does not contain confidential data.

On the left is how it looks after I just load what I saved yesterday. It has random zeroes in the documents' tables. They always grow back if I try to fill them with relevant information and save the file, but only visible after loading the file.

On the right you can see what I have harvested out with the other free office suite and what I wrote into the tables yesterday.

Not all tables of the document are affected, but always the same ones - unless I write more text as sometimes the set of affected tables change.

Will try if I can save in other format now if I manually copy the original data back and if reloading issue goes away in some other format as it is likely save/load issue.
Comment 7 Richard Thier 2020-06-02 17:19:55 UTC
thanks Telesto!
Comment 8 Richard Thier 2020-06-02 17:25:06 UTC
(In reply to Telesto from comment #5)
> Created attachment 161537 [details]
> Example file
> 
> 1. Open the attached file
> 2. Select the table
> 3. Apply Sidebar -> Table Styles -> Box List Green
> 4. Save & Reload -> Part of the content replaced by 0

I can also confirm this and also add that the other two apps still read the file after your steps cripple it, so likely the data is not "lost" but cannot be loaded.
Comment 9 Richard Thier 2020-06-02 17:29:31 UTC
(In reply to Telesto from comment #5)
> Created attachment 161537 [details]
> Example file
> 
> 1. Open the attached file
> 2. Select the table
> 3. Apply Sidebar -> Table Styles -> Box List Green
> 4. Save & Reload -> Part of the content replaced by 0

Doing the same and saving to docx does not make the bug appear so it seems this only affects odt format.
Comment 10 Richard Thier 2020-06-02 17:36:32 UTC
Interestingly if I re-save the badly loading document with some other app that can read the file, I can once again open it in libreoffice without data loss too - so I am not sure if it is loading or saving issue or both.
Comment 11 Lars Becker 2020-06-02 17:53:50 UTC
I can confirm this issue. I also have occasional data loss with tables with  LibreOffice (fresh, 6.4.4).
Comment 12 Telesto 2020-06-02 18:31:28 UTC
@Heiko
Is it an option to disable (uncheck) the Font and Number format formatting by default for all the (default) table styles... [Table -> Autoformat Styles]

Would solve - or at least for now prevent - this & bug 133179..
Comment 13 Heiko Tietze 2020-06-03 10:42:13 UTC
(In reply to Telesto from comment #12)
> Is it an option to disable (uncheck) the Font and Number format formatting
> by default for all the (default) table styles... [Table -> Autoformat Styles]

Don't think so. If you load a document, the TS is taken from the what has been stored regardless any checkbox. We have a) the situation to apply a TS to existing content with the expectation that cells containing text must not be formatted as numbers, and b) somehow Richard managed to loose data and I don't follow how exactly.
Comment 14 Telesto 2020-06-03 14:42:36 UTC
No issue with with Number formatting disabled
Version: 5.2.5.0.0+
Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55
Locale: nl-NL (nl_NL); Calc: group

Text is replaced with Number Formatting enabled, however already visible after applying.. not only after save & reload

Bumping priority, concerns dataloss, quite easy to into it.. it's a hideous bug.. needs a save & reload before visible.

Priority based on:
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 15 Heiko Tietze 2020-06-03 17:15:47 UTC
Duplicate of bug 125075?
Comment 16 Telesto 2020-06-03 17:41:03 UTC
(In reply to Heiko Tietze from comment #15)
> Duplicate of bug 125075?

It's related.. and has some elements.. However.. this about 'text' being replaced by '0' after save & reopening.. bug 125075 does the same thing, except the change is visible after applying the style.. not after save and reload.. 

However, related to the same table layout rework...
Comment 17 Oliver Brinzing 2020-06-05 04:15:02 UTC
maybe related to:

Bug 131025 - Writer document with tables lost data in cells (apparently) replacing with 0
Comment 18 Telesto 2020-06-05 07:35:12 UTC
(In reply to Oliver Brinzing from comment #17)
> maybe related to:
> 
> Bug 131025 - Writer document with tables lost data in cells (apparently)
> replacing with 0

It is.. as table style applies numbered formatting...
Comment 19 Telesto 2020-06-07 18:59:11 UTC
*** Bug 133732 has been marked as a duplicate of this bug. ***
Comment 20 Xisco Faulí 2020-06-11 14:34:40 UTC
(In reply to Telesto from comment #5)
> Created attachment 161537 [details]
> Example file
> 
> 1. Open the attached file
> 2. Select the table
> 3. Apply Sidebar -> Table Styles -> Box List Green
> 4. Save & Reload -> Part of the content replaced by 0

I can't reproduce it in

Version: 7.1.0.0.alpha0+
Build ID: 03b77f972f6be23f75dfe3773266a660e61e5607
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Win only ?

OTOH, when you say Reload, do you mean File - Reload or closing the document and opening it again ? or is it reproducible either way ?
Comment 21 Telesto 2020-06-11 14:41:32 UTC
Created attachment 161884 [details]
Screencast
Comment 22 Telesto 2020-06-11 14:43:53 UTC
OK, Win only..
Comment 23 Xisco Faulí 2020-06-11 14:45:26 UTC
(In reply to Telesto from comment #22)
> OK, Win only..

Yes, I can reproduce it in

Versão: 6.4.3.2 (x64)
ID da versão: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
Processos do CPU: 1; SO: Windows 6.1 Service Pack 1 Build 7601; Gestão da interface: padrão; VCL: win; 
Configuração regional: es-ES (es_ES); Idioma da interface: pt-PT
Calc: threaded

but not in

Version: 6.4.4.0.0+
Build ID: 4f8325dbcb63627997289889a377a4893e03fcf1
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 24 Xisco Faulí 2020-06-11 15:14:35 UTC
In my opinion, LibreOffice should not apply the number format to a cell if the cell already has content. This issue is basically that, the cells has Text format and when the autoformat is applied it changes the cell's format to number, thus AB is converted to 0.

@Heiko, What do you think ?
Comment 25 Heiko Tietze 2020-06-11 15:24:38 UTC
(In reply to Xisco Faulí from comment #24)
> In my opinion, LibreOffice should not apply the number format to a cell if
> the cell already has content. This issue is basically that, the cells has
> Text format and when the autoformat is applied it changes the cell's format
> to number, thus AB is converted to 0.
> 
> @Heiko, What do you think ?

The point of (table) styles is to format existing content. So we should format cell content but not convert text to numbers or vice versa. If you format a cell in Calc as number, date or percet that contains text nothing is lost. Whether cell format is not applied or not effective in the end (which is the case in Calc) is up to the devs.
Comment 26 Richard Thier 2020-06-11 15:41:20 UTC
(In reply to Telesto from comment #22)
> OK, Win only..

I did not try 7.x, just what I wrote, but I was not on windows, but on arch linux. Both 32 and 64 bits I tried actually if it counts.

Just to clear up what win-only means... I do not see if 7.x has this win-only and not on linux maybe if you meant that but I felt "win only" being ambigous as the issue was on my linux laptop and PC.
Comment 27 Telesto 2020-06-11 15:47:30 UTC
(In reply to Richard Thier from comment #26)
> (In reply to Telesto from comment #22)
> > OK, Win only..
> 
> I did not try 7.x, just what I wrote, but I was not on windows, but on arch
> linux. Both 32 and 64 bits I tried actually if it counts.
> 
> Just to clear up what win-only means... I do not see if 7.x has this
> win-only and not on linux maybe if you meant that but I felt "win only"
> being ambigous as the issue was on my linux laptop and PC.

Hmm. Win Only means, happens only on Windows... This is the case for the way I reproduce this. So there is another route, causing the same issue which affects Linux too.
Comment 28 Telesto 2020-06-11 16:22:36 UTC
repro on mac
Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; VCL: osx; 
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 29 Lars Becker 2020-06-11 16:46:51 UTC
I haven't found a way to reproduce this error systematically, but occasionally I have this problem on Arch Linux (currently with LibreOffice 6.4.4.2 40(Build:2)), so it's not Windows only.
Comment 30 Eldieke 2020-06-17 12:46:23 UTC
Hello,

I have the same bug.

Libre Office Writer
OS: ArchLinux
Libre Office version: 6.3.6.2
Build ID: 6.3.6-1

Here's the exact steps before it happened:

1. Opened Libre Office Writer
2. Choose View > Web
3. Table > Insert table. Choose a preset Format.
4. Filled table. Content: numbers, numbers+text, text
5. Set font color, italic, align.
6. Saved, close LO.
7. Opened LO. Italic, color and align had disappeared.
8. Put them back again.
9. Repeated steps 6 and 7.
10. Set personal style for one of the rows: grey color
11. Saved, close LO.
12. Opened, added content, saved.
13. Opened LO: text+numbers content had disappeared, replaced by "0". Personal style created: still grey, but content lost as well. Text-align (out of any custom style): lost.
Comment 31 Telesto 2020-06-19 11:25:33 UTC
*** Bug 134144 has been marked as a duplicate of this bug. ***
Comment 32 Telesto 2020-11-04 13:46:36 UTC
*** Bug 137977 has been marked as a duplicate of this bug. ***
Comment 33 Telesto 2020-11-04 13:48:42 UTC
This might even be a duplicate of bug 131025.
Comment 34 Richard Vendelbo Nielsen 2021-03-30 19:30:30 UTC
Hello. I can reproduce the same bug in version 7.1.0.3 (x64)

Steps to reproduce:
- Create a new document in LibreOffice Writer.
- Create a new table with Style = None
- Enter some data into the table.
- Change table style to "Box List Green"
- Save the document, close the program and reload the document.

Result: All text in the table, except for the first row, and the first column, will be replaced with '0'.
Comment 35 Richard Vendelbo Nielsen 2021-03-30 19:33:07 UTC
(In reply to Richard Venelbo Nielsen from comment #34)
> Hello. I can reproduce the same bug in version 7.1.0.3 (x64)
> 
> Steps to reproduce:
> - Create a new document in LibreOffice Writer.
> - Create a new table with Style = None
> - Enter some data into the table.
> - Change table style to "Box List Green"
> - Save the document, close the program and reload the document.
> 
> Result: All text in the table, except for the first row, and the first
> column, will be replaced with '0'.

On Windows 10 btw.(In reply to Richard Venelbo Nielsen from comment #34)
> Hello. I can reproduce the same bug in version 7.1.0.3 (x64)
> 
> Steps to reproduce:
> - Create a new document in LibreOffice Writer.
> - Create a new table with Style = None
> - Enter some data into the table.
> - Change table style to "Box List Green"
> - Save the document, close the program and reload the document.
> 
> Result: All text in the table, except for the first row, and the first
> column, will be replaced with '0'.

OS: Windows 10 Pro
Comment 36 J-Paul 2021-05-15 14:32:52 UTC
Same problem with Writer 7.1.2.2 on Ubuntu GNOME 21.04 Wayland

A text document. A table with text inside. Several changes in the format.

When I save it and close, and open it again, a part of the text is replaced by 0,00 €

And they are others bugs in these tables : add a line by using the tab key loses the format you have done and come back to the original format of the table !
Comment 37 Heiko Tietze 2021-05-17 07:33:41 UTC
Just to mention again: The issue is caused by table styles. Because of bug 49437 we had to create the new TS including all attributes such as number format. Some TS (eg Financial) presume a numeric value and text becomes 0.
Comment 38 Lars Becker 2021-05-25 12:54:36 UTC
This is really very annoying.  In an NGO we had one user recently had a major data loss because of this behavior, because it was forgotten that we had the problems some month before.

While from a technical standpoint the behavior might be correct, from the users point of view it is not understandable for most users and even for those who understand why this might happen it's not transparent, since there is NO way to display and verify those settings.

In practical terms that means we're going back to MS Office since table usage there doesn't result in potentially MAJOR data losses.
Comment 39 Richard Vendelbo Nielsen 2021-05-25 14:08:02 UTC
Until this bug gets fixed, a possible way to circumvent it when you want to change table style, would be to:

- Copy the table and paste below.
- Change the style of the new table to what you want
- Save and reload the document. See that the new table has lost data.
- Select the cells of the original table and copy.
- Select the cells of the new table and paste.
- Delete the original table
Comment 40 Andreas 2021-05-27 08:29:42 UTC
(In reply to Richard Vendelbo Nielsen from comment #39)
> Until this bug gets fixed, a possible way to circumvent it when you want to
> change table style, would be to:
> 
> - Copy the table and paste below.
> - Change the style of the new table to what you want
> - Save and reload the document. See that the new table has lost data.
> - Select the cells of the original table and copy.
> - Select the cells of the new table and paste.
> - Delete the original table

Sorry, but this is not a workaround, this is pain in the ass!

Everyone, who can remember this, know that he don't should change the table style. And when someone forget the table style problems, he also would not use this way of work ...

It would be a better option to delete this table style until it is fixed!
Comment 41 Buovjaga 2021-10-25 11:04:39 UTC
Bug 131025 comment 51 says the document in this bug is fixed now as well. Could everyone re-test? The fix was applied 23 Oct, so can be tested with Win or Mac daily builds available at least https://dev-builds.libreoffice.org/daily/master/current.html
Comment 42 Richard Vendelbo Nielsen 2021-10-29 14:02:55 UTC
(In reply to Buovjaga from comment #41)
> Bug 131025 comment 51 says the document in this bug is fixed now as well.
> Could everyone re-test? The fix was applied 23 Oct, so can be tested with
> Win or Mac daily builds available at least
> https://dev-builds.libreoffice.org/daily/master/current.html

I've just tested with version LibreOfficeDev_7.3.0.0.alpha0_Win_x64 - 2021-10-29 05:25:14, and the bug is still there.

Steps to reproduce:
- Create a new document in LibreOffice Writer.
- Create a new table with Style = None
- Enter some data into the table.
- Change table style to "Box List Green"
- Save the document, close the program and reload the document.

Result: All text in the table, except for the first row, and the first column, will be replaced with '0'.
Comment 43 Richard Vendelbo Nielsen 2021-10-29 14:07:49 UTC
(In reply to Richard Vendelbo Nielsen from comment #42)
> I've just tested with version LibreOfficeDev_7.3.0.0.alpha0_Win_x64 -
> 2021-10-29 05:25:14, and the bug is still there.
> 
> Steps to reproduce:
> - Create a new document in LibreOffice Writer.
> - Create a new table with Style = None
> - Enter some data into the table.
> - Change table style to "Box List Green"
> - Save the document, close the program and reload the document.
> 
> Result: All text in the table, except for the first row, and the first
> column, will be replaced with '0'.

Sorry, i accidentally opened with the normal version. Testing with the new version, the bug seems to be fixed. No text has been altered.
Comment 44 Buovjaga 2021-10-29 14:41:46 UTC

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