'No rows to display' - then no more records after clearing the filter.

[TonyLeech]

I have the same issue reported by "robgell" on the forum April 19, 2014 (04:38:06 pm).

When non-matching text is entered into the filter textboxes and correctly obtains no records the message "No rows to display" is shown.  But even after clearing all the text from the text boxes so that a full table list should be displayed (i.e. all db rows) the message "No rows to display" remains and there seems no recovery from this state except to reload the webpage.

As this is the same thing reported by "robgell" I was wondering if anyone knows what solution was implemented there because I must be missing the same thing or doing the same thing wrong.

[paramvir]

It works fine for both local and remote filtering, You could check the server requests/ response in the browser developer tools and find out the reason.

Please share a jsfiddle or a test case if you are unable to resolve it.

[TonyLeech]

There must be something wrong in my php when no rows are returned.  Now that I think about it it's the same sort of thing I've had each time there's been a bug in my php i.e. it runs fine until the problem hits then no table changes occur until after a full web page refresh.  I have to admit that php is still relatively new to me.  I thought that each php call should 'refresh' as if being run for the first time, but something certainly seems to 'stick' when the code fails due to bug or poorly written code.  I think I know where to look now.  Thanks for the guidance.

[TonyLeech]

* UPDATE *

So I found the bug in the php.  I'll report it here in case it can help others.  The following code is extracted from the remote paging demo...

    $skip = ($pq_rPP * ($pq_curPage - 1));

    if ($skip >= $total_Records)
    {       
        $pq_curPage = ceil($total_Records / $pq_rPP);
        $skip = ($pq_rPP * ($pq_curPage - 1));
    }

When there are no records to return due to non-matching filter the variable $pq_curPage will return 0 due to ceil() function.  Any future request results in a negative $skip value due to ($pq_curPage - 1).  Negative offsets are not allowed in the LIMIT clause...at least not in mySQL (not familiar with other databases to comment).

Hope this helps someone.

Thanks.

Tony