Created attachment 134583 [details] XLSX file with formula containing large range Steps to reproduce : 1) Open the attached xlsx file 2) Select cell B4 and do "ReCalculate" (Data > Calculate > ReCalculate) 3) B4 now shows error : #NAME? instead of the value 6. In the attachment the cell B4 has the formula =SUM(A2:BZZ2) and row 2 has values only upto column C. LO supports only 1024 columns(upto AMJ), but I think for large ranges in formulas should be truncated by the available columns(ie in this case, A2:BZZ2 needs to be truncated to A2:AMJ2) while importing from xlsx rather than reporting an error.
i did the steps and yes confirmed, but looking in the formula the second part of the sum is lowercase(=SUM(A2:bzz2)), this is because the BZZ2 column does not exist; it most be ABZ2 and you can recalculate without the #NAME error Version: 6.0.0.0.alpha0+ Build ID: 959be1b5a9cd522394dba9366686a1256588223b CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-11_00:18:59 Locale: nl-BE (en_US.UTF-8); Calc: group
i am sorry for the noise because it did not read the description properly; but one thing i can't understand is why LibreOffice must be a clone of or in the worst case the same as M$Office
Moving to ASSIGNED since there is a patch in gerrit for this bug: https://gerrit.libreoffice.org/#/c/39815/
Truncating ranges to actually supported columns is not a good idea. While it works for SUM() if cells in excess columns were empty, it fails and silently changes the result if they were not empty. It also does not work for functions that take the argument as array and empty cells are evaluated as 0 to be calculated with. Already COLUMNS(Range) delivers a different result, and something like COLUMN(Range) in array context with Range truncated truncates also the resulting array with column numbers, so for example {=SUM(COLUMN(A2:BZZ2))} would give a different result instead of Error.
(In reply to Eike Rathke from comment #4) > Truncating ranges to actually supported columns is not a good idea. While it > works for SUM() if cells in excess columns were empty, it fails and silently > changes the result if they were not empty. It also does not work for > functions that take the argument as array and empty cells are evaluated as 0 > to be calculated with. Already COLUMNS(Range) delivers a different result, > and something like COLUMN(Range) in array context with Range truncated > truncates also the resulting array with column numbers, so for example > {=SUM(COLUMN(A2:BZZ2))} would give a different result instead of Error. Yes makes sense, I see lots of problems that way. I guess now the only feasible way is to push forward the work on tdf#50916. Thanks.
Dear Dennis Francis, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 6.2.0.0.alpha0+ Build ID: d9ad59da50c1172fe98f94370221c9c1b688200a CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-08_23:34:44 Locale: ru-RU (ru_RU); Calc: threaded
Now very large sheets are somewhat supported, but enabling that and opening this file makes Calc instantly crash in current 7.1 master. Version: 7.1.0.0.alpha0+ (x64) Build ID: dda71436b8594fb0669b3ac06c02a3997a0674be CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
no crash and no repro the problem from the description in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 96e1be11540bada172fbdbfbbe3f9b7dc3e58462 CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Jumbo Note: Jumbo feature should be enabled. Should we close this one as WFM now?
Issue fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=8bb457d17ef970676f60976cc4e2de9c9f5340c0 author Luboš Luňák <l.lunak@collabora.com> 2022-02-07 16:09:58 +0100 committer Luboš Luňák <l.lunak@collabora.com> 2022-02-10 11:59:39 +0100 commit 8bb457d17ef970676f60976cc4e2de9c9f5340c0 (patch) tree fa9d46cde0577f4b26bd9bedada7ef309ad59ea9 parent a6eddceda5d376cd73922123a3bb3a5683307c41 (diff) dynamic logarithmic columns in ScBroadcastAreaSlotMachine Closing as RESOLVED FIXED
*** Bug 134550 has been marked as a duplicate of this bug. ***
*** Bug 136546 has been marked as a duplicate of this bug. ***
*** Bug 146861 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b4c131cf4237ed7d4e4be1212318c818dc943fce tdf#109061: sc_jumbosheets: Add unittest It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.