F
franchiset
Guest
Hi, How can we limit and page the number of records that are pulled down from the AppServer per request? We are trying to build a simple transaction viewer grid that displays selected transaction information. The BE is read-only, no create/update/delete. The transaction table has more than 61,000 records and all records are pulled down and read into the grid before the grid displays. It takes more than a minute before the UI is first displayed. Navigation within the records is quick once the grid has been built. We'd rather the grid be displayed quickly with perhaps 10 or 100 records to start with. The user can then enter the appropriate filter with (e.g.) the desired date range and another request should go back to the AppServer to retrieve another data set. Even with no filtering, as the user navigates through the data, the UI should make requests as needed for more from the AS. We see the references to implementing [myCount and setting serverPaging to true] here: documentation.progress.com/.../ documentation.progress.com/.../dvwsv.pdf We tried implementing the myCount method (but not JFP stuff), but no records are returned and the KUIB app displays an "Unexpected response from 'MyCount' operation" error. Questions: 1. To implement paging to reduce network traffic as described above, do we need to implement the JFP input and myCount things (including adding a seq and id to probably every table that's accessed by the KUIB) as documented above? 2. Are there any working app code samples that implement such paging? 3. Is there a simpler, more maintainable way to implement paging to reduce network bandwith? It's just not practical in any real app to always bring down thousands of rows every time a data grid is displayed. I just wonder about the long term maintenance that we'll need to implement all these back end and front end customizations to make the apps perform in a usable manner. Thank you. Regards, Carl
Continue reading...
Continue reading...