1. Select an entire column
2. Define it as a Named Range - by default it misses out the last row, so change
the definition to include row 1048576
3. Put a value in row 1048576
4. Do a VLOOKUP looking for the same value from another cell in the named range
5. Delete a blank row from the sheet
The VLOOKUP result will change to #N/A. The named range should have changed to
cover rows 1 to 1048575, and the value is in row 1048575, but the VLOOKUP fails
to find it.
Behaviour observed on Go-oo, will try on LibreOffice beta tonight.
I can't reproduce this using the latest build of LibreOffice. So, please try the latest beta of LibreOffice to see if the problem is still there.
BTW, I like your reporting style. It's very easy to follow for us developers and help us try to reproduce the problem better. :-)
I'll keep this bug in the meantimee.
Damn, it isn't doing it now! Same version, same process, the range is being created correctly (last row 1048576) and it doesn't break when I delete a row. I promise it was failing earlier! I can't think of anything I have done differently - maybe I had opened an Excel file earlier prior to creating a new ods spreadsheet. I'll try and replicate it again.
Looks like no reproducible case has been provided. Feel free to re-open if you find a way to reproduce this reliably.
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.