OFFSET and NEXT ROWS part of an Aggregate
Aggregates & Queries
Platform Server Release Oct.2019 CP1

Looked at the Large List Navigation Sample in the Forge today, I think this should be part of the Aggregate for faster lest memory intensive data fetching.

That project on forge is mine, and I think it can also be implemented in scaffolding for lists.

I wonder whether this is the way to go for large data sets. Apparently (see here and here) there is an increasing performance penalty as one accesses "pages" closer to the end of the result set. An alternative is to apply the "seek method" (see here for more details). There's a discussion going on this topic in the forum. Follow it here.

Hi Everyone

Came up on this problem recently on the aggregates. I understand the OFFSET-NEXT performance penalty when compared to the Seek method, but I still think that this should be implemented on the Aggregate's optimized SQL, as it is sure to have better performance than the 'Select TOP (n)'  that is being currently used. That will lead to even worse performance as a user browses further back since it will bring more and more records from the query. 

@OutsystemsTeam any updates on this (IMHO) excellent idea?



We've cases that low performance is notable and our databases still growing up.

Then OFFSET-NEXT can turn pain less.

Something like this is implemented in Reactive Web Apps:

Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.

Changed the status to
on 02 Oct 2018

Hi Matthias,

Indeed we have implemented this in screen server aggregates for mobile and reactive web apps. From our research, this is where pagination is more often needed. We might implement this in other places in the future (server aggregates that are not screen aggregates, local aggregates, traditional web..., feel free to open other ideas if you feel you need those). Read more about the new reactive web apps here.

Thanks for your idea,
Tiago Simões

2016-04-21 20-09-55

added the idea for traditional web apps, because it's very much needed/wanted for pagination in web services!

Hi J,

Will you please include a link in your final post, to your traditional web apps idea.



@J. , @Tiago Simões  was this idea for traditional apps ever implemented? 

I needed this idea as a way to OFFSET and  go through records and update records from where I left off via a loop in a server action (not present the data through a screen and use pagination) 

@Tiago Simões

Was this idea ever implemented for server side logic?

I'm implementing a REST API that I need to paginate the results...