https://bugs.documentfoundation.org/show_bug.cgi?id=160018
--- Comment #17 from Colin <[email protected]> --- (In reply to m_a_riosv from comment #15) > Can you test with a newer version, 7.6 is EOL since Jun-2024. > > Maybe the option > Menu/Tools/Options/LibreOffice Calc/General/Update references when sorting > range of cells. Hi again, Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: sv-SE (en_SE); UI: en-GB Calc: threaded I've just re-retested because I recalled from earlier interactions where somebody noted that if the sorting is performed on any column other than the first column, it didn't appear to break the array. Not sure whether this was observed in Windows or Linux I thought I'd insert an additional "blind column" ahead of the desired working sort column to see if it would mitigate. I never got around to experimenting in that manner. I used a "Filled" copy of the spreadsheet and sorted on one of the other value columns to verify the integrity of that "secondary column" sort. The issue is far more critical than I initially identified - IT BREAKS THE MATH IN ADDITION TO THE SORT. Attached is a replacement "filled" sheet already primed with J5 selected and its array unhidden. 1 Observe the value in the merged pink array E2:F3 1975.53 2 Using the autofilter at J5 Sort Descending 3 Observe all the "summaries" in column C 4 Observe all the "summaries" in column J 5 Observe the "summary" in the E2:F3 array 6 Ponder on the possibility that the mathematical destruction is seriously impacting other unobserved/undocumented aspects of the integrity of any sheet utilising autosorted named arrays. -- You are receiving this mail because: You are the assignee for the bug.
