Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Incorrect results when using pagination activity in repeat grid



User have a Grid Repeat which uses a custom Pagination activity. Pagination activity handles both Pagination and filtering. On Filtering the grid column the results are getting duplicated by an OOTB prpc activity.

Error Messages

incorrect results shown on screen. incorrect pxResults count

Steps to Reproduce

Are mentioned in detail along with the screenshots in the attached doc.

The same can be found here:
1. Launch the Field Marketing Portal using the below access details:

2. Open one of the Campaigns from My Campaigns
3. Click on the Edit link for Campaign Contacts(2nd Row)
4. Now Click on the Filter Icon on the EMAIL column
5. Filter by [email protected]
6. Expect Count after Filtering is 8 - Which is correct
7. But the Grid results shows 16 records and Clipboard page is also having 16 records which is incorrect

Root Cause

The root cause of this problem is a defect in customer application code/rules. It was found that a custom pagination activity was used for progressive load on the repeat grid. The pagination / sort activity does not fetch all the data / records at once.  With each call it enables pagination and configure the page size to their desired viewing size. 

The custom pagination activity is not written in a way that supports “progressive load” and was different from @baseclass.pzGridSortPaginate in terms of the behavior. 


Local Changes suggested: 
Changing the pagination mode of the grid is one way to resolve the issue. Modes: Page 1,2,3 ; Page 1 of X work well with the custom activity that fetches all records at once. But, results are displayed in pages. This change should be made in  section PegaMT-Work-Campaign. ContactListViewerManual. The other way to resolve this is to change the custom pagination activity to support “Progressive Load”.

Developers were able to resolve this issue based on the brief description on how “Progressive pagination” currently works in PRPC. In the second call to our activity user were not setting .pyPagingSettings.pyPageIndex on the report param page, which previously was not required.  In a similar manner developers are now required to set Param.currentPageIndex = 1 after a filter because it is no longer provided for the first call to our pagination activity ( causes our thread to hang ).

Published January 31, 2016 - Updated October 8, 2020

Was this useful?

100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us