Every software product has it’s bits of tribal lore, those unintuitive quirks that when revealed make you say “aha!” and feel empowered to mentor others.
A QlikView factoid of this variety is that: “General Script Error” from a script STORE statement usually means that the target directory does not exist. For example, a “General Script Error” from the following statement if “somedir” does not exist:
STORE mytab INTO somedir\mytab.qvd;
it could actually be any type of output file error. Could be missing directory, could be locked file or an illegal file name, You know this. You’ve been using QlikView for some time.
I include this tidbit in my beginner classes, and the students are usually grateful to be receiving these “inside tips” . But occasionally, I get a Programmer type in the class who slowly raises one eyebrow Spock fashion and asks “Why doesn’t it throw a ‘Directory not found’ message'”? I’ve never been able to give a satisfactory answer to that question, (This is usually when I announce lunch).
Someone pointed out to me recently that:
Which is supposed to allow Script to continue after errors, does not affect STORE output file errors. That is, the script still fails with “General Script Error”. This is because the STORE file error is Uncaught/Unhandled. You’ll recognize this construct if you’ve done any programming.
It’s not like Script can’t catch IO errors. For example, input errors are handled just as you would expect. These statements won’t cause the script to stop even though “foo.bar” does not exist:
SET ErrorMode=0; LOAD X FROM foo.bar;
Most of QlikView — both script & UI — fails and recovers extremely gracefully. I don’t know why STORE seems to have been left out in the cold.
P.S. I’ll be at Qonnections next week. Let’s see how many of us can ask “Why doesn’t STORE catch output file errors?” at the R&D Q-Bar. J