Apache OpenOffice (AOO) Bugzilla – Issue 84878
#NAME? in attached .xls with many shared formulas
Last modified: 2017-05-20 10:45:05 UTC
Please see attached file (it is .rar archive, you would need Winrar from www.rarlabs.com) - when opened in Calc it displays "#NAME?" in many cells, which Excel does not. For example, cell AK11 contains formula "=D11*G11", but Calc shows "#NAME?".
Created attachment 50573 [details] Test case packed
Hi Daniel, please have a look at this one. Frank
problems in shared formulas import... started
fixed in SRC680/dr58 (OOo 2.4)
Daniel, I just love you! Thanks a ton. Regards, Kirill. P.S. What was wrong so that we could not correctly open the file?
In the Excel file, the formulas are stored as "shared formulas", means the formula is stored once for an entire range of cells, and all cells refer to this formula, instead of containing a copy each. Resolving the refernces from the cell to the shared formula was somehow broken, but only in your example, maybe the file is too big, so there were buffer overflows. It always worked in my example documents.
sigh... not fixed ... seems that I used a wrong test document. DR->NN: while loading this document, the named ranges collection reaches its limit of 2^14 entries. Is this limit still up-to-date?
reopened
Hopefully we would not miss 3.0 with this issue.
Maybe 3.1?
*** Issue 124416 has been marked as a duplicate of this issue. ***
confirmed, test case still fails to load all formulas and shows #NAME?
It really is a problem of a size limitation of the ScRangeName class. Its base class ScCollection defines in sc/inc/collect.hxx the value of MAXCOLLECTIONSIZE to be 16384. This limit is tested in ScCollection::AtInsert() and, if reached, the insert request is silently ignored. It is almost a wonder that the import works at all. An experiment with changing MAXCOLLECTIONSIZE to 32768 fixes the bug for this particular bug document. Instead of just enlarging the limit it might be good to know why it exists in the first place (i.e. why is the container not dynamically growing) and why it has the value 16384.
I checked some other core data stuff in calc and a lot of it seems to be allocated like this historically (fixed max of sheets, fixed num of rows/cloumns, ...). I would guess it was never changed to dynamically due to fear to get slower and the massive amount of spots to change (which in practice can be done and is often much less problematic than expected). I do not think there are other reasons, though...
Reset the assignee to the default "issues@openoffice.apache.org".