Joomla! Documentation™

This code does not work correctly as it stores the limitstart into a session variable. So, when clicking upon the first item in your pages list, no limitstart variable is present and so the previously saved limitstart value is reused.

ie. you can go to pages 2, 3, etc. but not back down to 1.

A work around I have used is to always get the value from the Request object.

//$limitstart = $mainframe->getUserStateFromRequest($option.'.limitstart', 'limitstart', 0, 'int');

$limitstart = JRequest::getVar('limitstart',0);

Confirmed and fixed. Thanks. Chris Davenport 23:03, 31 May 2009 (UTC)

I have one question

The example changes to the model seem to call the query twice, once with and once without the LIMIT. Should this not use the same SQL_CALC_FOUND_ROWS method mentioned in the "Examples with JDatabase" section? Crispy 11:49, 28 October 2009 (UTC)

Yes. Please go ahead and change it. Chris Davenport 18:39, 28 October 2009 (UTC)

Using SQL_CALC_FOUND_ROWS is not necessarily better, particularly for indexed queries: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?. Chris Johnson 23:08, 30 October 2009

Besides the questionable efficiency impact, the listed implementation of the SQL_CALC_FOUND_ROWS suffers from a race condition that may cause concurrent pagination requests to get inaccurate counts by resetting FOUND_ROWS()'s data before it can be checked in the subsequent request. Combining the queries something like SELECT SQL_CALC_ROWS NULL AS count, x, y, z FROM xyz LIMIT a, b UNION SELECT FOUND_ROWS() AS count, NULL AS x, NULL AS y, NULL AS z ORDER BY CASE WHEN count IS NULL THEN 1 ELSE 0 END then dealing with the special case first row in PHP probably makes it atomic, but I have to wonder if it's really worth the added complexity. Ralph 02:22, 29 January 2010 (UTC)