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:
SET ErrorMode=0;
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.
-Rob
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
I’ll ask as this annoys me quite a lot! Have though about writing a sub-function but haven’t found a way to found out if the existing qvd is “locked” (this is the case 95 % of the time for me at least).
We usual kill all open QV.exe processes with a vbs script before starting etl load:
‘Kill open QV.exe processed before ETL Load
Set objShell = CreateObject(“WScript.Shell”)
taskkill=”taskkill /f /fi “”USERNAME eq “” /im qv.exe”
objShell.Run taskkill
WScript.Sleep 10000
taskkill=”taskkill /f /fi “”USERNAME eq “” /im qv.exe”
objShell.Run taskkill
WScript.Sleep 10000
taskkill=”taskkill /f /fi “”USERNAME eq “” /im qv.exe”
objShell.Run taskkill
WScript.Sleep 10000
taskkill=”taskkill /f /fi “”USERNAME eq “” /im qv.exe”
objShell.Run taskkill
WScript.Sleep 10000
Additionally, we restart all qvservices with a Batch file before etl load.
Doing so, all potentially locked QVD files are unlocked again.
Regards – Marcel
And if you want to get it fixed… there is an idea on Qlik Community… 🙂
https://community.qlik.com/ideas/3443
It would make a very useful Sub Routine in QlikView Components – Call SafeStore. I guess a FileList of a missing directory would return much the same as an empty one? May have to go try that…
I did get someone at Qonnections to write this as a bug, at least the uncaught problem, But I don’t know if it will be accepted by R&D.
I like the idea of the SafeStore routine. Creating the directory if it didn’t exist would require giving Execute permission to the script. Do you think that would be acceptable to people?
I always try to avoid giving Execute permission. Even if the script bombed with a handled error message it would be better than just closing without a message and the ability to step over that line of code. Raising the error would be simple, working out that it would fail, and not calling the actual STORE could be trickier.
For some though, Execute may not give them any concerns.
You would also have to consider file locking. I suppose this could be dealt with (again with Execute permission) by attempting to rename the old file before saving the new, then deleting the renamed file after the write.
All good fun.