When inserting rows in some distance to the cell containing summation, then the summation area is changed in severely wrong manner - totally unexpected. See examples (calc files and screenshot) 1) Summations in row 5 and in row 9 (each column E) 2) Marking some row numbers at the left border and choosing "insert rows" in the right-mouse-click context menue (and inserting nummer "5" in one of the new cells) shows correct and expected behaviour: the summations are not affected. 3) Marking as much row numbers at the left border, that row 5 also is marked (to insert 4 rows above former row 3) - then the summation area is enlarged, wrongly including rows 5 to 8 (new counting), even though rows 7 and 8 are not changed, only transferred downwards. Expected behaviour: row 9 is not changed, relative adresses in the summation should still relate only to this row itself (before: row 5, afterwards: row 9) with no change into an rectangle area. 4) Marking more row numbers at the left border and choosing "insert rows" leads to an even stranger behaviour: the summation area is enlarged, containing other blocks of numbers now. I proposed severity "major" and priority "high", since this behaviour really affected some complex spreasheets of mine during the last months. 1) Totally wrong numbers arised (apparently in random manner) 2) It was not easy to identify the source of that confusion. 3) And even with that knowledge now - it is still much work to check all summations within the spreadsheet that could have been affected when inserting some rows.
Created attachment 96942 [details] spreadsheets before and after inserting rows, screenshots showing areas used in the formula file upload was not successfully in the first step
Hi. Your step-by-step is hard to follow, because the screenshots don't show the "ABCD" landmarks. You say that 1)-2) is right ; which is wrong, 1)-2)-3) or 1)-3) ? I didn't manage to reproduce the bug (LibO 4.2.2.1 on Win7). It would be kind of you to provide a more explicit step-by-step.
Created attachment 97656 [details] spreadsheet & screenshots, before & after inserting rows load the spreadsheet and look at the screenshots to test the bug
Today I updated manually (!!) LO, uninstalling vers. 4.2.2 and installing the vers. 4.2.2.3. Still the same bug exists! my OS is 64-bit Windows7 SP1
edit; unistalling 4.2.2.1
This may be the same bug I just found. I have a spreadsheet with some cells containing sums of other cells. If I insert new rows above the sum range, the sum range is not adjusted correctly. The end of the range is correctly increased by the number of rows added, but the beginning of the range stays at the original value. The effect is that the formula now sums too many rows. I insert the rows by selecting several rows, then using Insert > Rows in the menu. The number of rows inserted does not seem to matter. If rows are deleted instead, both the start and end of the sum range are adjusted correctly. I found this in 4.2.3.3. I upgraded to 4.2.4.2, hoping that it had been fixed, but it's still there. I am using Windows 7. I tested this with version 4.0.1.2 on my old XP computer, and it does NOT have this bug. As I write this, I've done a little more playing around, and this seems to happen only if the rows I have selected in order to do the insert overlap the sum range. Example: Cell E14 contains =SUM(E4:E13) I want to add 7 rows after row 1, so I select rows 2-8 and then choose Insert > Rows in the menu. 7 rows are added; cell E14 is now E21 and contains =SUM(E4:E20) It should contain =SUM(E11:E20), since the rows I added are outside the sum range.
I've looked at Steffen's attachments now, and am pretty sure it is the same bug. Looking further at the bug lists, #77647 seems to be the same thing, and is listed as fixed in 4.2.5.0. That appears to be scheduled for release in June. I can probably work around the bug until then (just use multiple, smaller inserts that don't overlap the sum range).
Created attachment 99358 [details] Workflow video insertion/deletion rows
Comment on attachment 99358 [details] Workflow video insertion/deletion rows LO vers. 4.2.4.2 Using the command "insert rows above", after Selecting a row with a cell containing a reference to a range, the range is altered. Unexpected results, operating on the same Resulting range, even with the use of "Delete selected rows". The same thing happens with any command that uses the range.
FURTHER COMMENTS: When this bug happens in a large spreadsheet, it causes the program to crash. When the crashed file is restored authomatically at the next start, in all the cells where there were functions, these are substituted by numbers!! This unaspected modification is "invisible": it happens without any warning from the program. On the contrary, using MS Office to open the restored ods file, a warning of defective file is given, and the "modified" cells are highlighted as errors. Now I'm back to using "Apache OpenOffice" vers. 4.1.0, as it does not have this very dangerous bug.
Seems that enough informations provided, set UNCONFIRMED
I think we need expert opinion here.
As Nancy said, perhaps duplicate to Bug 77647
(In reply to comment #3) > Created attachment 97656 [details] > spreadsheet & screenshots, before & after inserting rows > > load the spreadsheet and look at the screenshots to test the bug Following the test case, I can't reproduce under LO 4.2.5.2 - Ubuntu 12.04 x86. Perhaps related to Bug 77647 fixing. Please REOPENED if anyone can reproduce in latest stable release
(In reply to comment #15) > (In reply to comment #3) > > Created attachment 97656 [details] > > spreadsheet & screenshots, before & after inserting rows > > > > load the spreadsheet and look at the screenshots to test the bug > > Following the test case, I can't reproduce under LO 4.2.5.2 - Ubuntu 12.04 > x86. Perhaps related to Bug 77647 fixing. > > Please REOPENED if anyone can reproduce in latest stable release Christian, maybe this bug was fixed under your "LO 4.2.5.2 - Ubuntu 12.04 x86". But I confirm that this bug still exists in the test ods file, opened with my LO 4.2.4.2 (Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8), which is the latest stable release in my Windows7 64-bit SP1 Operating system.
Mariano, you can only reopen a bug if you can reproduce with same or higher version...not with older.. And don't forget to reset user profile to make sure its freshness. 4.2.5 has arrived for Windows: http://www.libreoffice.org/download/libreoffice-stable/?type=win-x86&version=4.2.5&lang=en-US *) Anyway, curently LO has no 64bit version for Windows