Please complete your question.
The help on this page is mainly provided by users like you.
Your question and the corresponding description should be as detailed as possible.
Please remember that no one can look over your shoulder when you ask your question and describe it.
In order to be able to help you as quickly as possible, we need to know your operating system and the LibreOffice version (three digits, e.g. 7.3.2).
Please also state the file type in which you have saved your file.
All important information about your initial question should be present in the initial question box, otherwise edit and complete it., to do it.
Please do not use answers (solutions) or comments for this.
If you have already fulfilled some of these requirements, so much the better. Thanks.
Here you can find the further References for this page.
This is irrelevant. I assume this is a response to
but this original part of the error message has nothing to do with Calc’s columns/rows. It’s about line and character position in the XML where the read ended when the problem was detected; and XMLs inside ODF are kept without newlines - so basically, an XML looks like
<?xml version="1.0" encoding="UTF-8"?>
<office:document ... a REALLY long line, maybe hundreds of millions of characters, with thousands of ODF elements and all the data ... >
and so, most of the time, the error is somewhere in that overlong second line, at some character in the middle of its insane length … giving that 2,321994355(row,col). There are occasions when the XMLs contain some newlines in its data, and those newlines could break the overlong line 2 into several - and then you could have some other number instead of “2” in the error message … but that is another story.
@jcldfltr0803 without the problematic file, and some work on its internals to try to recognize and manually fix the incorrect format data there, there’s nothing to be done with this. And if you have a reproducible scenario how to arrive at such a corruption from a normal state, please file a bug report.
The .ods zip container’s content.xml file is corrupted. Unzipping that Finances.ods gives inflating: content.xml bad CRC 5d76e49c (should be 24e01654)
which means the zip file’s data was modified after been written. That may be due to a failing hard disk, a driver error, any software overwriting things. As you provided the file via Dropbox, if you are using that with folders you’re storing documents in it may also be related or the culprit.
In a pretty-printed (processed by XML reformatting ignoring errors) form starting at line 7256977 of ~7265199 or so content.xml contains quite some garbage (bad element names) that gets worse and worse including actual data corruption towards the end of file and is beyond being easily repairable. Best restore from a last known good backup. But probably you don’t have any, otherwise you wouldn’t have asked here. For the future, Preventing data disaster - The Document Foundation Wiki .
If someone knowledgeable invests time one might be able to reconstruct quite a portion of the document content, but much of everything following the garbage start will be lost. Searching for badness start in an editor the regular expression table-[^=]*[0-9] seems to work, finding table:table-cell table:num7er-columns-repeated= instead of table:table-cell table:number-columns-repeated= and scrolling down reveals more and more garbage and after a while there’ll also be 20able:table-20ab instead of <table:table-cell and getting worse. It seems the zip file entry’s character repetition table is broken.