Issue in Section Access

[kicchu465]

Hi Team,

I have implemented section access in my application.

When I execute the script I am facing the error.

The code is given below.

FOR i = 1 to $(vL.Reduction_Field_Count) //Basic for loop using the counter we generated earlier

//Join join our table here as part of the loop and dyunaically build the fieldname based on

//our variables

LEFT JOIN(GROUP_TABLE_temp)

LOAD

ACCESS As Access_1

//,NTNAME As GROUP

,COMBINED_NAME AS NtName_1

,REDUCTION_FIELD_VALUE AS $(vL.Reduction_Field_Name$(i))

RESIDENT SECTION_ACCESS_TEMP

WHERE REDUCTION_FIELD ='$(vL.Reduction_Field_Name$(i))';

//At the sametime on our loop, we'll create some useful fields for later

//to give us the list of different table fieldnames, end datamodel field name

//and field numbers. These will all be used later to dynamically build the end table

REDUCTION_FIELDLIST:

LOAD

'$(vL.Reduction_Field_Name$(i))' AS FIELDLIST

,'$(vL.DataModel_Reduction_Field_Name$(i))' AS DATAMODEL_FIELDLIST

,$(i) AS FIELD_NO

AUTOGENERATE 1;

NEXT i;

DROP TABLE SECTION_ACCESS_TEMP; //Drop no longer needed temp tables

Error which I am facing as below.

      2018-02-27 16:38:25 0211          AUTOGENERATE 1

      2018-02-27 16:38:25              3 fields found: FIELDLIST, DATAMODEL_FIELDLIST, FIELD_NO,

      2018-02-27 16:38:25      2 lines fetched

    2018-02-27 16:38:25 0213 NEXT i

      2018-02-27 16:38:25      Error: Unexpected token: 'SECTION_ACCESS_TEMP', expected one of: ',', 'AutoGenerate', 'From', 'From_Field', 'Inline', 'Resident', 'Where', ...

      2018-02-27 16:38:25      Execution Failed

      2018-02-27 16:38:25      Execution finished.

Could you please advice.

Thanks,

SK

[Chanty4u]

Marcus Sommer maybe pcammaert  can help

[marcus_sommer]

I assume that the loop didn't worked as expected and I would probably use some trace-statements to find where it breaks and how there the content of the variables look like. I mean something like:

trace $(i) - '$(vL.Reduction_Field_Name$(i))';

- Marcus

[Peter_Cammaert]

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

P.