there is something that always has me a little worked up when working in QlikView, that's when you have some app with an error in the script you haven't spotted, the app runs for 5min or more and then it produces an error ...
Isn't there a possibility to quickly check the script, maybe even using another little app where you copy and paste the code to be checked or something, before you actually run it? Such a solution would of course not spot every little thing, but for example if you have an ApplyMap() in a LOAD and you forgot the keyword "Mapping" when LOADing the corresp. map, that's a thing such a solution could find and it would save you a lot of time ...
Is there something like that around or would I have to write that myself?
In my opinion is the use of the debugger with a record-limit the most practically way to check if a script runs through and that there are no synthetic keys or any loops within the datamodel. Beside this syntax check and the general datamodel check it could be also helpful to identify logically issues like missing or wrongly used key-statements like mapping, left, right, inner and so on without loading all data.
Well, it would be nice to have such an elementary syntax checker. However, as you have probably seen already in every spot where Qlik tries to accomplish just that (expression editor, script editor etc.), there are various reasons why it is close to impossible to do better than what we have at the moment AFAIK these are such reasons:
Statement order vs Code execution order: imagine that the table without MAPPING prefix is used for something else, and inbetween that MAPPING-less LOAD and the subsequent use of an ApplyMap, there is a CALL to a SUB that does define the mapping table. How would the syntax checker figure out whether there is an error at all?
$-sign substitution: this is the nemesis of all analysis tools and efforts. $-sign substitution forces you to simulate/execute all preceding statements before you can actually analyse a $-substitution loaded statement at all.
The world of run-time errors vs the separate world of syntax errors. Actually specifying a mapping table name that is nowhere to be seen until then is not a syntax error by itself. Up until recently, it wasn't considered an error at all. In the most recent QV12 versions, Qlik has intelligently classified it as an run-time error, which makes early discovery at least a little bit more probable. But you'll still have to run your code before the missing table is detected.
One solace: there are entirely different remedies to make script coding more efficient and recover some of the lost time. Marcus has already mentioned one (shorten your development cycle and you will discover your bugs easier and faster). Another one is the modular approach to programming: write your code in (almost) self-contained units and test them on their own using input/output specs and data. You can use the SUB...END SUB container for that. And a third one is really a more process-oriented approach: use code reviews to detect the things you don't see and at the same time improve the implementation of functional specs. There is a famous saying in the OSS world: "the more eyeballs, the shallower the bugs". These techniques offer no guarantee that you will find every snag, bug or omission before you first run your code, while some of them are better suited for teams of two or more people, and the popularity of code reviews may go up&down every so often... But they certainly help It you're concerned about the frustration and cyclic wall bumping and head hitting during typical QlikView development sessions.