Product Improvements For Variables?

On 2 Oct, I was pleased to join a group of eight Qlik Luminaries on a field trip (we had a bus!) to Qlik R&D in Lund, Sweden.  Ralf Becher has written a nice overview of the trip here.

One outcome of our meeting is a list of enhancements we believe would be valuable additions to QlikView and Qlik Sense.  You can view the entire working list here.

The list includes quite a few topics.  Today I want to focus on improvements to Variables.

A common challenge is”script only” variables getting inadvertently promoted to the UI.  There is a desire to better control and identify variables in the script.

What follows are a number of specific feature improvements for variables raised during the meeting.  The general theme is to extend the current management functions for Fields to Variables as well.

  •  A HidePrefix and $hidden Tag for Variables.  Hidden variables would not appear in the Variable overview or Expression Editor dropdown unless “Show System Variables” was checked.
  • A “DROP VARIABLES vg*” statement.  The DROP VARIABLE statement would delete a list of variables from both the script and UI. Script deletion of a UI variable is not possible today. Importantly, the list can include wildcards.
  • Script functions that provide access to  existing variables.  Similar to functions currently available for Fields, the functions would be:
    • NoOfVariables()
    • VariableName(nbr)
  • COMMENT VARIABLE varname WITH ‘comment’
    Currently the only way to add comments to variables is through the Variable Overview dialog or the VBScript API.  Comments are a useful feature and it would be great if comments could be set using script statements.

What do you think?  Would you use these additions?  Are there additional improvements you would suggest for Variables?



12 thoughts on “Product Improvements For Variables?”

  1. Hi Rob,

    Big thank you for your effort to get these improvements from the whichlist to the tasklist, my compliments! I am sure I will use all these improvements.

    I am not a big fan of the “Variable Overview dialog”, I assume I am not the only. New functions like : variable search, variable rename, and variable export (allow copy/paste in table format to excel) can be simple enhancements for us all.

    Regards Daan

  2. Hi Rob.

    Totally agree with the idea. Rouge variables can be a real problem in QlikView. I always train to define all variables in the script and before going live delete them all, run the script and check everything still works.

    Also, the method of dropping variables in the script is a bit hit and miss. Especially when de-bugging as script variables with values remain.

    This seems like such a simple idea I don’t see why it’s not been considered before.


  3. Thanks Rob for sharing this! Personally my biggest issue is dollar sign expansion with parameters – we use this feature a lot to store measures in the spreadsheet and the biggest pain that you cannot use comma and have to do workarounds. Maybe your suggestion to implement escaping characters will do the trick.

    Dropping variables will be nice but we can leave with that 🙂

    What QV and Sense really need is a way to store meaasures and dimensions and inject qualifiers like TOTAL or set analysis expressions to them. Sense cannot do that still. I really like the suggestion to load Sense master items from a script – that might help. But still you would have to create 10-20 different measures like Sales for YTD, Sales to MTD etc,

    Also I LOVE the idea to improve calendar, working with dates is a major pain and something that new developers struggle a lot. Tableau handles dates very gracefully.

    1. @ boris
      I don’t find working with dates a major pain . And I prefer the Qlik approach to tableau. Tableau may be easier for new developers in this respect only (although I found it easy enough starting out and overall find Qlik Sense far and away better than Tableau) but when dates are set up Qlik is superior from a user viewpoint by some distance. And quickly looking at Power BI it seems to have followed the Qlik approach.

  4. Scoping and easier disposal would definitely be beneficial.

    I’ve also found it advantageous to manage variables in an Excel spreadsheet, which provides searching, categorizing, sorting, disabling, and other advantages. It is also much cleaner when having to use quotes and dollar signs in the definition, versus a .qvs text file. These are loaded with a simple load script construct:

    LOAD Variable as $Variable,
    Expression as $Expression
    (ooxml, embedded labels, table is variables)
    where len(Disabled)=0;

    LET vVars = NoOfRows(‘Variables’);

    For i = 0 to $(vVars)-1
    LET vVarName= Peek(‘$Variable’,i,’Variables’);
    LET $(vVarName) = peek(‘$Expression’,i,’Variables’);
    NEXT i;

  5. The five improvements I would like to see in Qlik sense is

    -Unlinking a sheet from the main App filters (selections) when required.
    -Drill around.
    -Making null automatically selectable (I know this is unlikely).
    -Including an advanced searching option (like Power BI) under the selection menu.

    Mini charts I think should be avoided. Just a waste of time or do users actually like them?

  6. Perfect list Rob, I would definitely use most of them.
    I would like see the functionality to categories the variables according to custom category. Like NPrinting variables, Sales Expression, Finance Expression and so on…

  7. Hi Rob,
    I tend to maintain all my expressions in the variable editor and I know others keep theirs in the script but I like the syntax check on the expression. The improvements I would like are:
    Make the window full screen. It is like working through a keyhole.
    Allow editing of the variable name in the variable editor. It would be even better if that would update all references to it in the qvw.
    Allow a find and replace in the variable editor.
    When you create a new variable, you have to then find it at the bottom of the list before editing it. It should default to the new one.
    Fix the bug where the syntax check fails whenever -= appears in the editor.
    These would be a great improvement.

    1. Also when you type the name of a variable in an object expression, it gives you autofill options once you start typing, which helps avoid typos. However, if you put $( before the variable name it does not, so you have to type the variable name in and then go back to put $() around it which is time consuming.
      Also, in the variable overview, if you press enter anywhere in the definition window, it immediately closes the window without saving your changes. If you have updated more than one variable you have no idea what has or has not been updated.
      The undo function does not apply to changes in the variable overview. This would be very useful also.

  8. Hi Rob,
    As Mark Dorio already mentioned, the main issue is scoping of variables – everything is dumped into the global scope (which even extends beyond script into the UI).
    Ways of limiting this scope would include the ‘easy disposal’-way you described above, but why not approach it the other way around? Scope variables to script only or a single SUB by default, and allow for some construct (e.g. ‘DEFINE’ instead of ‘LET’/’SET’) to handle variables that should go into a larger scope.

    On a separate note: introducing some kind of namespacing, with proper support from the UI, would be nice. It’s easy enough to define variables like ‘vFormat.Date’, but the bits of the UI that handle variables treat all of them alike (leading to one huge list of color variables in some of our apps, with a few functionality-related variables sprinkled inbetween).
    But perhaps I’m just repeating Zeeshan Adeel’s words here?


  9. Hi Rob,

    I’ve been working a lot with variables and yeah, it’s a bit of a struggle, every of your suggestions could really help!

    Apart from variables the one thing I would really like to see implemented are chart level set analysis.


  10. Hi Rob

    One improvement I would like to see in variables is if there was an option (either by individual variable or on the whole document) where Qlikview could retain variable values when Server performs a refresh on the client.
    Currently the functionality in Qlikview allows keeps the user’s selections and sheet they are on, but all variables reset. I use variables to show/hide objects and sheets as users click on particular objects, so when the document refreshes on the client it can reset what the user is looking at in the document.
    Hope I’ve explained the issue, I’m sure others must have felt the same pain if they are using variables in the same way.

    All the best


Leave a Reply

Your email address will not be published. Required fields are marked *