Aggregate not returning the same count when copied to the Action

I have copied the aggregate from the preparation to the server action and it returns different counts. Any solution for this issue?

Do you have any filter that could be changed between the preparation and the screen action?

I assum ethat by "count" you're talking about the Lenght of the List.

In this case, the problem is that when the Aggregate is in a Server Action, the platform is not able anymore to know where it will be used. 

If you are using the aggregate to feed a Table Records, for example, it will be able to know how many records it should fetch based on the number of lines you set to show in the Table. But if you put the aggregate in a server action, this is not possible anymore, and the aggregate will fetch 1000 thousand records (just an example), even if your table records is shown only 10. 

Another problem is that when in preparation it fetchs only the columns you effectively uses, when in Server Action, for the same reason, it fetchs all.

If you're talking about the COUNT property of the aggregate itself, the only reason (I think) for this to happen is that you changed something in the aggregate (filters, joins, etc), or you are passing different values for variables that you're using in filters, joins, etc.

Hope this helps.


I am passing the date filter which is same in both aggregates.. I am here trying to make a common action which will be called both in preparation and in the change event of combo box

In that case, it seems that Eduardo's answer might help you. When you use the Count property of an aggregate, it basically does this:




Or, in other words, does a "super-query" using the aggregate as "sub-query". If you use the length of the result list, it may vary due to:

- Number of records that you want to fetch

- Number of rows in a table records widget (for instance), etc.

As such, due to your use case, I would suggest refreshing the query and the element on the OnChange action of a given combobox. It should do the trick.


It is a really bad practice doing like you're trying to do.

The standard and recommend way is doing like Armando explained.

You run the aggregate in preparation and bound it to the widget you want. In the screen action you are calling, if it is being called as Ajax Submit, for example, to enforce the filter, you execute a data refresh in the aggregate in preparation, and an ajax refresh in the widget.

If the screen action is called using submit, your action may even be empty.

This is explained in the online training. I suggest you to review it, or do it if you didn't yet.


Thank you Armando and Eduardo.