Aside from the golden tip by Marcus about how to find out what goes wrong during loop execution 3, you can fairly easily reconstruct the code that the script engine tries to parse (and that is giving it a fit). Consider this train of thought:
The script engine complains about encountering token SECTION_ACCESS_TEMP in the spot where it expects either a semicolon (indicating a Preceding Load) or a data source keyword.
However, the statement does have a RESIDENT keyword. Then why isn't this keyword treated for what it means: read from a Resident table ?
That's probably because the RESIDENT keyword itself is in the wrong spot, more precisely it is being eaten as something else. Remember that QlikView Script language doesn't really have reserved words! QlikView Script is a highly ambiguous language. What a word like RESIDENT will mean, depends on where the script engine finds it. It can be a table name, a variable name, a data source keyword, and ... the name of a new column...
And there you have it: if the script engine thinks that SECTION_ACCESS_TEMP should be a data source keyword, then this means that the actual RESIDENT word is eaten as part of the previous expression.
But why does the script engine add RESIDENT to the previous expression that creates - of all things - a new column? Usually (99.99% of all cases) that is because your $-sign expansion expands to ... nothing at all. Your statement then ends with
, REDUCTION_FIELD_VALUE AS RESIDENT SECTION_ACCESS_TEMP WHERE ...
And because RESIDENT is a perfectly valid name for a new field/column, you don't get any complaints there. But the SECTION_ACCESS_TEMP token will be unexpected. Compilers and interpreters have a hard time figuring out where the actual error is. Often they only report the consequences which may be located a distance away.
BTW that's also why Marcus' tip will save your day