If you create i.e. a list of 30000 10digit numbers (with duplications) in calc and try to apply the unique value functionality (data->filter), then the return list of values is wrong. Values that are unique are hiding at the end of the column with the duplicates ! (test it with the attachment)
Created attachment 46366 [details] calc file
can you please give more details ( step by step ) of what you do to set up the filter. Also if you show what values are in error it might help to see the problem you describe ( at least for me )
Created attachment 46412 [details] two columns with numbers
(In reply to comment #2) > can you please give more details ( step by step ) of what you do to set up the > filter. Also if you show what values are in error it might help to see the > problem you describe ( at least for me ) I did some more tests (you can use the attached files) and as I can see the problem is more generic. Just create a column with numbers ie from 1 to 20000 - something more than 16384 rows. Select the column and go at menu Data->Filter->Typical, choose this column not to be null, next press the button more options->no duplicates. The return rows are always 16385.
ok, clearer now, seems there is some bug imposing a limit on the rows in the result. Kohei, please can you have a look
(In reply to comment #5) > ok, clearer now, seems there is some bug imposing a limit on the rows in the > result. > > Kohei, please can you have a look Is there a how to or fix ?
Bug still present in version 3.4.3 (release). I have several data files with more than 40,000 lines of where I need to filter out duplicates, and the result always returns 16385 rows max.
Still [Reproducible] with "LibreOffice 3.5.3.2 (RC2) German UI/Locale [Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80] on German WIN7 Home Premium (64bit) Now works fine with parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8a78020]" (tinderbox: Win-x86@6-fast pull time 2012-04-18 23:51:20). I doubt that we can get the unknown fix backported to 3.5, so I close this one.
Created attachment 60658 [details] screenshots comparison shows that problem vanished for 3.6