Hi Ricky,

Currently the GUI simply selects all columns without taking the user into account. Values can be needed for Defaults/Layouts/Contexts etc. and are therefore selected. The GUI team has a backlog item to look more into performance innovations to make the GUI even faster but never got onto the sprint to be researched and implemented. So considering the Universal GUI is there, and Indicium is now the data supplier, the effort the (limited) team would have to put into researching and implementing this for the Windows and Web GUI would not be feasible.

For Universal GUI, Indicium already does not select data the user cannot see and the model does not use, so that's beneficial 

@Mark I’m wondering whether I can test that within Universal to see where my major benefits will appear - since that feature has not been implemented yet: 

or did you mean something else with this quote: “For Universal GUI, Indicium already does not select data the user cannot see and the model does not use”

Since one can say “since it is in the model - it uses it”?

rgds Ricky

btw Faster GUI is not the only factor in better performance (i.e. use less resources overall)

I maybe should put it differently. When using the Universal GUI (or sending requests for data to Indicium), your rights on the model decide what you can access and not access. If, for instance, I am not allowed to access the Employee table, then Indicium will not return the data. But that also applies for columns. If I don't have rights, I cannot retrieve values of that column. But Indicium will also not tell me I don't have rights on that column as, when it's unauthorized for me, Indicium will not confirm its existence to me.

So more or less Indicium will construct select queries based on the user's rights to show him the information that the user has access to, but will use columns that are needed to show Conditional layout for example even if you don't have access to that particular column. 

Ah - so my original questions remain open 

• Can you help me understand why are the selected columns in the sql query not matched with the logic behind a subject?

• How can I achieve a matching column set query with only the visible columns and the possible logic behind the subject so this can hit the performance drastically (sometimes for the bad, but most for the good of it)

The GUI team has a backlog item to look more into performance innovations to make the GUI even faster but never got onto the sprint to be researched and implemented. So considering the Universal GUI is there, and Indicium is now the data supplier, the effort the (limited) team would have to put into researching and implementing this for the Windows and Web GUI would not be feasible.

In short, it hasn’t been the priority to optimize.

The GUI does the queries, these can't be manipulated. Only way to get these queries more small is by having the table/view be more small I'm afraid.

Hi Ricky,

I just happen to find out there is an extended property you can use:

I hope this helps!

If I had the time and money enough to take the risk on implementing experimental stuff onto production I’d apply this in a heartbeat, but I’m afraid that lack of both sufficient funds prohibits me from doing this at the moment, though I love to hear when this gets out of this experimental phase and into production @Mark Jongeling 

Hi Ricky,

I just happen to find out there is an extended property you can use:

I hope this helps!

This only works for the Win/Web GUI at the moment.

Hi Ricky,

I just happen to find out there is an extended property you can use:

I hope this helps!

This only works for the Win/Web GUI at the moment.

Thanks Erik! Our production systems are not a playground for experimental stuff ;-)