How to avoid using queries inside ‘If’ branches in preparation?

Hello everyone.

I'm studying the platform and I encountered a situation that I couldn't understand completely.

Maybe we can discuss and propose a change in this (Performance Best Practices - Logic) article.

Here is the part I haven't understood (underline):
"Avoid using queries inside ‘If’ branches in preparation


Avoid using the conditional queries in preparation to prevent the extra query data from going to the viewstate.


When using refresh screens, take care with conditional queries (queries in "if" branches). To prevent this, declare a local screen variable and assign it from the query and with an empty record list in the beginning of the preparation.


If a query is only executed inside an "if" branch in the preparation and used outside that branch (in a table records, for example), its data need to be always in viewstate. This is because the query is only executed sometimes. This increases the page viewstate size.


Note that this only happens if we use the submit action that terminates with an end node (causing the screen to refresh). For AJAX actions and for destinations, this does not apply."

I understand that we should declare a local variable (record list) at the preparation's beginning. But how are we going to assign values to this local variable without an aggregate in the preparation? Or the goal here is only to get rid of the aggregate inside an 'if' branch? Should we have a screen action querying the data?

Hi Lopes,

the solution doesn't suggest you get rid of the query inside the if, sometimes that just is what you want to do, but it proposes that you avoid the large viewstate in case of submit by adding an extra local list variable holding either the query results or empty list, to base all your UI on.

Alternatively, if it's a fast query, there might not be much harm in always executing it, dependent on the situation.


Hey Dorine, thanks for your reply.

Does that mean that local variables aren't sent to the ViewState?

I have very little experience with traditional, was just giving my interpretation of the text.

But this is definitely worth an experiment, I would say.  

You could set that up, or else I'll find some time next weekend.

Or has anyone else on the forum tried this out already ??


Hi Lucas,

First of all I want to say that I really appreciate your question! I had this doubt on the past. But after I tried this "Logic" best practice I could really see the benefit, specially, for application's with high volume data / complex data models - with a lot of attributes.

First of all let me answer your question:

  • In Traditional Web Apps local variables are always loaded in the ViewState, regardless of its type or size.

Second point:

  • The final purpose of this best practice is to reduce a page's ViewState by cutting the query potential size from the ViewState. This way, you don't allow conditional queries (which in some cases could retrieve a substantial amount of data) to persist and overload the ViewState.

  • By using a local list variable you don't eliminate the ViewState at all. Instead you have the chance to hone it, by cleaning the local variable in the beginning of the preparation and populating it only for the case you really need it, which in turn depends on the outcomes triggered by the last "Submit" action.

I already had the chance to apply this practice on some of the projects I've worked, and I could see the substantial benefit / impact it had on the performance of Traditional Web Apps, specially when you are dealing with complex / high volume data applications.

I really recommend a study and analysis of this best practice before someone starts using the "Submit" method on actions.

I hope you find this helpful!

Best regards,

Hi Lucas! 

Dorine's interpretation is absolutely right! It's actually on point.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.