Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Weird problem...
We are using listboxes to control visibility of certain tables.
Data Structure behind it all:
The last column is used in the listbox like this:
And then we create (via a macro) variables for each of the rows like the following. This one is named vGebindeauswahlAn
We use that in the chart to control its visibility like
I have attached a sample QVW for you to get the idea behind the concept.
All this works fantastically well! Except with this one variable (vGebindeauswahlAn) in this one application and only in the QlikView Server
So it always works in the desktop version.
In the server it evaluates to true directly after reloading the app, but when changing to Einräumliste and then back to Gebindeauswahl, it evaluates to false.
Saving it back to the server helps, reloading the document helps and resetting the document state via the Access Point helps as well. All of which aren't really options and also don't explain what might be going on here.
We are using this in many other apps and never had a problem until now.
Any ideas?
Thanks,
Sandro
Turns out, it wasn't about the variable at all, it was about the diagramm, in which it was used.
It is in a different alternate state and thus the variable was sometimes evaluated in that context and sometimes in the default alternate state.
The difference in the desktop and server was due to a different version being used. It is QV 12.1 on the desktop and QV 11.2 on the server side. The handling of alternate states has changed between those major versions.
The solution was to explicitly add the default alternate state into the variable definition to make the result of the statement unambiguous:
Now the result is predictable also in QV 11.2
Case closed...
Turns out, it wasn't about the variable at all, it was about the diagramm, in which it was used.
It is in a different alternate state and thus the variable was sometimes evaluated in that context and sometimes in the default alternate state.
The difference in the desktop and server was due to a different version being used. It is QV 12.1 on the desktop and QV 11.2 on the server side. The handling of alternate states has changed between those major versions.
The solution was to explicitly add the default alternate state into the variable definition to make the result of the statement unambiguous:
Now the result is predictable also in QV 11.2
Case closed...