Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
michael_klix
Creator II
Creator II

Variables seem to be not 100% user specific?

This is my problem:

In a Sense App, we use variables to save user input. Based on these variables, by hitting a button, actions are kicked off that do selections in a field or simply the headline of a sheet is defined via such a variable.

Now the strange behavior: Sometimes, when two users are using the same published app simultaneously, user A gets the variable content from user B.

Up to now, I assumed that whatever a user puts into a variable via an input field or what the button extension writes into a variable is local. Did anybody see this behavior too?

We are using Sense February 2021.

Labels (2)
2 Replies
rnorris
Partner - Creator
Partner - Creator

Hi, came across this while searching for a similar issue, and thought I'd offer some insight for anyone who found this while looking for answers. 

What I've found, is that if you have frontend variables, changing them does not impact other users. (Otherwise it would be impossible to use them for the state of objects / colours etc without everything constantly flickering around). However, once you change a variable in the backend, it applies document wide. So if (as I suspect you're doing*) you run a partial reload, say, and during that partial reload you set a variable in the script, it will be set as such for all users.

To make things super tricky, buttons in Qlik are multi threaded, meaning, the sequence you put actions in doesn't really have any effect; they will all be called simultaneously. As such, you cannot have a button that calls a partial reload AND does anything else, because there is no guarantee that the 'anything else' will happen before or after the partial load. In fact, typically, it seems to get called after, but because the reload is in progress you get an error message popup. 

This means in practice, you kind of need two buttons for a front end partial reload, one to tee up and set all the variables, and then another which purely triggers a load. 

 

*If you're not, then apologies this probably doesn't have any bearing on your issue @michael_klix , and given the date of this message I suspect you solved the issue. But I always think it's prudent to leave assistance on these threads in case someone stumbles across them when searching for similar issues as I have just now.

michael_klix
Creator II
Creator II
Author

Hi,

and first of all thanks for some clarification. What I found out as well meanwhile is that variables are changed in all currently opened versions of an app as soon as the app is reloaded. While the apps are opened independently without reload, they are indeed local.

What destroys the local variables is that we use a partial reload, triggered by the user. In the moment a user triggers the reload, all opened apps are refreshed and the variables are filled with the values from the "trigger-user". And newly opened apps will get these values as well. Note this applies not only to variables in the script but as well frontend variables. 

As this behavior is really bad for us we use a dirty trick:
Each user gets his own version of the app using ODAG. Lifetime is set pretty short to clean up the mess. Now all apps are 100% private. Results in partly >500 apps,  but hey... after a week they are gone.

Finally a remark on the action button.

We use up to 10-20 actions in one button quite intensively and up to now there is no effect of parallel execution visible. Rather the opposite: We do things like selection in one dimension, then select possible in another then remove the first selection, then write a variable and do other stuff... all nicely one after the other and if I change the sequence, indeed it does not work.

The mentioned reload however is independant from this kind of button actions. We use a customized extension that executes Javascript and talks to the database via REST. This way we are able to write back into the database and trigger the reload at the end when the database sends a confirmation that data is in the table now.

 

keep qliking

Michael