Data reload clearing variables - alternative to variables for changing dimensions on objects?

[Huxleys]

I've configured my data architecture with my source databases and QVD layers to enable close to real-time data access in apps. I can get change data from my RDBS into QVD within a minute, so my reload times on apps can be every minute to provide fresh data. This is very useful for some business users and is a feature I wish to keep. 

However, when an app reloads it refreshes all variables. Currently I am using variables (not in the load script) with variable input drop-down objects, along with a master dimension simply dollar sign expanding the variable, to provide dynamic dimensions for sheet objects. This enables a user to change the time-axis on a line graph from days to weeks or months etc, or change the grouping from product code to product category or total units etc etc.

In practice, a user may change the dynamic input variables to change their view of the visualisations, but when the app reloads it will reset those variables meaning every minute they have to re-input their selections in the drop-down objects, causing no end of frustration.

Is there a way to achieve this same dynamic input to sheet objects without using variables? It's very frustrating that data reloads refresh variables not defined in the load script (I'm defining them in the sheet editor) and that currently I have to decide to trade-off real-time data or sheet dynamics.

Thanks!

[marcus_sommer]

Instead of variables you may use native fields to control the dynamic views. Means instead choosing day/week/month from a variable the same might be done from a field - which is loaded within an island-table and which is not related to the data-model.

[Huxleys]

Thanks for the reply. Do you have any details on how to implement this solution? Many thanks.

[marcus_sommer · Accepted solution]

Just loading per inline-table or autogenerate:

DimPeriod: load pick(recno(), 'Day', 'Week', 'Month') as DimPeriod
autogenerate 3;

and the user selects the wanted dimension and the objects contain something like:

[$(=only(DimPeriod))]

as reference. Instead of only() you may use maxstring() to ensure that the object always has a valid dimension.

[Huxleys]

This is great, exactly the solution I was looking for. I assumed it would likely have a performance impact, but I'm willing to sacrifice that to maintain data freshness.

Thanks again!

[marcus_sommer]

I don't think that this approach has a real performance disadvantages against the direct variables. Querying the quite small island-tables and transferring the selected/possible values to the adhoc-variable reference within the objects won't need much time. I would assume only a few milliseconds and very near to be not measurable.

[Huxleys]

So far that seems to be the case, though my model is not very large with the app I'm testing on. Frustrating that the variable solution doesn't work with frequent data reloads, but this alternative lets me keep my 1-minute data reloads for fresh data which is great. Thank you so much!

[Or]

In a small dataset scenario, this is likely true, but as datasets get bigger than can have an impact. Rob wrote this issue up some years ago and I believe it's still true today:

https://qlikviewcookbook.com/2015/06/the-impact-of-data-islands-on-cache-and-cpu/

Qlik's documentation also suggests avoiding data islands and replacing them with variables for best performance:

https://help.qlik.com/en-US/sense/February2023/Subsystems/Hub/Content/Sense_Hub/Apps/app-performance...

But again, this is not likely to have an impact with a small app (which is certainly the case here as it reloads every minute).