this was maybe already pointed out .
If you build a table with a pager based on a sql query in which you use the distinct keyword, Be sure to adapt your call to the pager_query() function in consequence.
you have to specify the fourth parameter of this function : $count_query. If you don't, the system will try with his own count query which is just a replacement of your select by a count(*). Which will get you more record count than you actually have with you query using distinct.
I was pulling on my hair for hours, becoming mad , not understanding why I had so many empty pages in the pager navigation colspan and then I found out in pager.inc this tricky count(*) replacement and there was light.
By providing your own count query (basicallly "select count( DISTINCT(your_field) ) from ... where ..." ) you solve the problem and get the whole page count right. I just tought I'd share that with you as it was pain for me to find out the solution.
Comments
especially true with term access module for 4.4.x branch
the module makes great use of patchs you have to apply almost everywhere.
and uses queries with the distinct keyword .
Again, it messes up the pager if no adequate count query is provided.
[Problem submitted as a bug to the term access project.]
[aka]marvin
8 years later and still an
8 years later and still an excellent post, i realised i had to add a count query but after frustration had got the distinct / count nesting the wrong way round!
I found the upper case helped.
In case it helps anyone my solution for searching certain profile fields that contain a string.
We didn't expect many results so could afford to add a user_load during the while loop.
Thanks