Issue 84878 - #NAME? in attached .xls with many shared formulas
Summary: #NAME? in attached .xls with many shared formulas
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: 680m239
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 124416 (view as issue list)
Depends on:
Reported: 2007-12-26 21:30 UTC by kpalagin
Modified: 2017-05-20 10:45 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.0-beta
Developer Difficulty: ---

Test case packed (1.22 MB, application/octet-stream)
2007-12-26 21:36 UTC, kpalagin
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kpalagin 2007-12-26 21:30:19 UTC
Please see attached file (it is .rar archive, you would need Winrar from - 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?".
Comment 1 kpalagin 2007-12-26 21:36:09 UTC
Created attachment 50573 [details]
Test case packed
Comment 2 frank 2008-01-09 15:24:34 UTC
Hi Daniel,

please have a look at this one.

Comment 3 daniel.rentz 2008-01-10 08:57:16 UTC
problems in shared formulas import... started
Comment 4 daniel.rentz 2008-01-10 10:00:31 UTC
fixed in SRC680/dr58 (OOo 2.4)
Comment 5 kpalagin 2008-01-10 10:21:35 UTC
I just love you!
Thanks a ton.


P.S. What was wrong so that we could not correctly open the file?
Comment 6 daniel.rentz 2008-01-10 11:05:20 UTC
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.
Comment 7 daniel.rentz 2008-01-14 16:14:18 UTC
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?
Comment 8 daniel.rentz 2008-01-14 16:17:42 UTC
Comment 9 kpalagin 2008-04-11 19:52:32 UTC
Hopefully we would not miss 3.0 with this issue.
Comment 10 kpalagin 2008-09-23 10:27:23 UTC
Maybe 3.1?
Comment 11 j.nitschke 2014-03-12 20:33:45 UTC
*** Issue 124416 has been marked as a duplicate of this issue. ***
Comment 12 j.nitschke 2014-03-12 20:44:13 UTC
confirmed, test case still fails to load all formulas and shows #NAME?
Comment 13 Andre 2014-03-13 14:56:46 UTC
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.
Comment 14 Armin Le Grand 2014-03-17 19:33:15 UTC
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...
Comment 15 Marcus 2017-05-20 10:45:05 UTC
Reset the assignee to the default "".