gianni said In many applications we need to use complex filters options, de facto discarding occurrences coming from DBMS with physical pagination 

Ciao Gianni, let me well understand...when you use this kind of filter, your app apply the filter to the result set in memory? Why you don't inject the parameters directly in your RDBMS's query? Ciao Claudio

Claudio said

gianni said In many applications we need to use complex filters options, de facto discarding occurrences coming from DBMS with physical pagination 

Ciao Gianni, let me well understand...when you use this kind of filter, your app apply the filter to the result set in memory? Why you don't inject the parameters directly in your RDBMS's query? Ciao Claudio  

Hi Claudio, reasons to use discard on the recordset coming from RDBMS are related to complexity. When complexity can be reduced into a single query we are happy to do it: - adding further selections into the main query - using more or less complex views ...but it isn't always possible because: - the query or the view can become TOO complex and slow! - the selection must work on a computed field using primitives from N entities Sometimes discarding in a later stage become the best choice available... Hope it is more clear now... Ciao, Gianni

Hi Gianni, there is my old concept on: http://unifaceinfo.com/forum/uniface9/paginationproblemsolvedbyproperdatapreparation/#p2337388 One can use a STANDARD multi-purpose table, if we put a uniface list of the key=values and store it in a single field. It can be made pretty flexible and it is very fast because the re-retrieve with all keyfields is a direct access.