Recently I blogged on Include Files in QlikView, and mentioned the fact that QlikView doesn’t advise you when an include file was missing. This led to a discussion on QlikCommunity and a revelation to me of a new feature. This feature is not documented in the QlikView help files and Google turned up just one result for it.
The function itself is not revolutionary, but it is going to cause me to have to go back and modify many QlikView apps to use it. As I described in my previous blog, you can include code from an external script file simply by referencing it like this:
$(Include=..\Scripts\ExternalScript.qvs);
This is all well and good, provided that ExternalScript.qvs exists. However, if you have a typo in your file name then QlikView will happily just ignore your include statement and get on with the load script. That is until it references that table you thought you loaded in your include file. Debugging this could take some time – as the error will not necessarily occur anywhere near where you include failed and unless you are aware that QlikView doesn’t raise errors on missing includes you may not suspect that is the fault anyway.
This seemed to me like a bit of a flaw in how QlikView handles includes.
However, someone has obviously noticed this at QlikTech and with just a small change to your code:
$(Must_Include=..\Scripts\ExternalScript.qvs);
You will get an error message raised on any missing scripts. This will alert you in Desktop mode, or send abort your load and send a notification in batch mode. To my mind a much more useful thing to do than to keep the missing file quiet.
Many thanks to Toni Kuatto for posting about this feature on QlikCommunity.
There have been other occasions where there is a seemingly un-documented feature in QlikView that really helps makes things better, the AllowDataLineage flag being a recent case in point. I’m sure there are many more of these that I am yet to uncover.
If you are able to tip me off to any more of these, please leave a comment below.
Steve, what is use of data lineage ? And thanks for sharing must include option
Hi Hari, the Data Lineage feature stores details of what connection strings and queries were made prior to a QVD being saved. This means you can examine a QVD’s header to see exactly how it was created.
Hi Steve,
Thanks for this tip, will no doubt prove very useful!
I’ve got another little tip in exchange, while not exactly a secret you do not find it referenced very often (even QlikView syntax highlighting doesn’t seem to know about it); the WHEN and UNLESS statements.
These statements can be used as shorthand IF expressions:
WHEN (IsNull(Variable)) LET Variable = ‘Default value’;
UNLESS (Statement = True) SET vVariable = ‘Something’;
Cheers,
Barry
Hi Barry – there seems to be a lot that syntax highlighting is not aware of. *= and -= in Set Analysis for starters. I wasn’t aware of WHEN and UNLESS so that is another tip I can thank you for.
Excellent tips both. Thanks!
Thank you, Steve. This is really useful. I too need to go back and amend quite a few scripts.
Indeed, Rob, the I’ve not had a need to go back and rework so much since reading Information Dashboard Design by Stephen Few!
[…] No, this post isn’t about that negative co-worker or friend who’s always second-guessing your ideas and solutions, it’s about two QlikView script statements that I believe deserve a little more attention: WHEN and UNLESS. (Inspired by Steve Dark’s post on Hidden QlikView Features) […]
Thanks for this tip Steve!
Undocumented, but would this also mean unsupported? I mean, perhaps not available in next QlikView versions. How do you see this?
Hi Martijn – a customer of mine asked exactly the same question. In truth, I don’t know. I can’t see why they would remove such a universally useful feature. The question has been posed to QlikTech on QlikCommunity – I will see if I can get an official response here also.
Many thanks Steve. Very useful tip. I need to revisit some of my scripts.
Cheers,
DV
Hi Deepak – it seems amazing to me that QlikTech have introduced this feature without telling anyone!
Hey Steve, hope you are ok. very useful tip! i will be telling all of my colleagues about this!
Hi Chris – indeed – of all the things I have blogged about must_include is the thing that the most people have said they will need to change their previous apps to incorporate.
Steve,
This is wonderful. I now wonder if it makes sense at all to use include in the first place? It seems that using Must_include is the way to go.
Another little tricky part is the case sensitive nature of Qlikview. Many new developers who are familiar with traditional SQL programming find it difficult to know that Qlikview is case sensitive, so typing exact name of the field is required. And the worst part is that Qlikview is not giving any error messages or even warning about the error.
Hi Shilpan – thanks for your comment. I certainly have been updating a lot of my includes to use must_include now.
The case sensitivity is fine if you are consistent and tidy. I agree it can be a problem for some people though.
@Shilpan
I believe you are right for more than 90% of cases.
Still, here it is a possible reason to keep include as a secondary including option:
During some old times (when we didn’t know about must_include), after some big headaches when parts of the included script was not executed due to qvs naming changed or whatever, we added an error handling engine that was exiting the script once an included QVS was missing. But prior to that we were using an execute command line to send an alerting email to the qlik admins.
@ Steve & Barry
Thank you both for these great tips !
Hi Cotiso,
Agreed, there are cases where the standard Include is useful. I have used it as a quick and dirty way to optionally insert code into a load script. This way when a QVW file is copied from a location without an include to one where there is it can behave differently. It doesn’t feel quite right to have an include that you are half expecting not to be there – but it is a quick and dirty way of having optional code.
The -= notation can be replaced using the e() function.
The e() function is recognized by the syntax check and thus allows you to correctly check the syntax after the exclusion compared to -= where everything after this will be ignored by the syntax check.
Both the p() and e() functions are pretty usefull and are well documented within the help function of QlikView desktop.
Thanks for the tip on Must_Include, this will prove usefull in a soon to be implementation!
Hi Erwin, I would have thought that -= and E would give a different result. The first is not matching a specified values (or list of values), and the second is where a value is not selected in a specified field. I agree that the P() and E() functions were a very useful addition to Set Analysis syntax, particularly when used alongside data islands.
Hi again,
If you would for example do something like: [Field]-={‘val1′,’val2’}
You can simulate the same behaviour using set analysis within the e() function like this:
[Field]=e({})
Basically this will ‘soft-select’ (only for the current calculation) the values in [Field] and then only include all other [Field] values.
Off course this becomes really weird to read, but I’ve chosen this option in the past when more complex calculations and set analysis followed after the exclusion allowing me to keep using the standard syntax check function.
Something seems to have gone wrong in my last reply…
The e() example code should be:
[Field]=e({})
Hope it worked this time, otherwise I think this code is compiled into some wordpress tags or something :s
[…] Hidden QlikView Features (Quick Intelligence) […]
Thanks for posting this feature about Include.. It’s really helpful… Cheers!!!
[…] 1. Hidden QlikView Features via QuickIntelligence […]