Qlik Community

Ask a Question

Qlik Sense Advanced Authoring

Discussion board where members can learn more about Qlik Sense Advanced Authoring.

Announcements
Welcome to our newly redesigned Qlik Community! Read our blog to learn about all the new updates: READ BLOG and REPORTED ISSUES
cancel
Showing results for 
Search instead for 
Did you mean: 
Creator
Creator

Variable Evaluation in the Script

Hello there,

I am a bit puzzled by this and wonder if anyone can explain please:

In the script I use variables to store and pass values e.g.

1 - A date is referenced in a table

2 - This date is passed to a variable using the following:

Let vReportMonthEnd =     date(peek('ReportMonthEnd', -1,'ReportMonthLatest'));

3 - This variable is then used later in the script, within another table for comparison purposes

Date('$(vReportMonthEnd)')               AS MaxDateClaimId,

The question is, why does the variable needed to be wrapped in single quote marks for it to evaluable properly???

I thought single quote marks were for strings, but this should be a number.

The following does not work:

 Date($(vReportMonthEnd))               AS MaxDateClaimId,

Many thanks,

Colin

 

 

 

 

 

Labels (3)
1 Solution

Accepted Solutions

Good question, Explanation here we go.

Example:  

'03/06/2019' // D/M/Y format

This string will interpret as string when we have data format as DD/MM/YYYY hence there is no impact to evaluate

Example:  

03/06/2019

When this string is used as a part of an expression, it will be numerically interpret as 3 divided by 6 divided by 2019.

Before develop something, think If placed (The Right information | To the right people | At the Right time | In the Right place | With the Right context)

View solution in original post

4 Replies

Good question, Explanation here we go.

Example:  

'03/06/2019' // D/M/Y format

This string will interpret as string when we have data format as DD/MM/YYYY hence there is no impact to evaluate

Example:  

03/06/2019

When this string is used as a part of an expression, it will be numerically interpret as 3 divided by 6 divided by 2019.

Before develop something, think If placed (The Right information | To the right people | At the Right time | In the Right place | With the Right context)

View solution in original post

Creator
Creator

Yes, the date passed to the variable is in the format DD/MM/YYYY.

A great explanation. Still a little puzzled by one aspect.

The date format we see is effectively the text element of the underlying field value:  dual(text, number), and this is the textual representation of the underlying number e.g.  03/06/2019 is the text interpretation of the number 43616.

Does the dual format not apply to variables?

Also, why is there no need to use Date# in this case.

Thank you,

 

 

Partner
Partner

Hi,

This is because you don't store it as a dual and Qlik doesn't recognize the 43616 as a date. 

When Qliks engine recognizes a date automatically, a Date# is not needed. A Date# is used to interpret the dates that Qliks engine is not recognizing and often used as a save option (Because versions of Qlik can differ in handling this). For example, 03062019 is a date, but Qlik does not recognize this and for this you need Date#.

Jordy

Climber

Work smarter, not harder
Creator
Creator

Hi,

Thanks for the reply.

so hopefully this is right:

The following evaluates as an actual date:

Let vReportMonthEnd =     date(peek('ReportMonthEnd', -1,'ReportMonthLatest'));

In the variables box during debug mode, it is evaluated as:

vReportMonthEnd     30/04/2019  (Note: no quote marks around DD/MM/YYYY)

Furthermore in the Charts "=IsNum(vReportMonthEnd)" calculates as -1 (true).

 

However, during the script load, the formula:

Date('$(vReportMonthEnd)')  is evaluated as Date('30/04/2019').

Qlik Sense in this instance recognises that the string '30/04/2019' is a Date (due to matching the System Variables) so it gets processed as a Date.

Conversely, Date($(vReportMonthEnd)) is evaluated as Date(30/04/2019) which is really Date(0.03715) an evaluates to a date of 01/01/1800.

So perhaps a date of '30-04-2019' might not be recognised.

Cheers,

Colin