Inconsistent results when the DateFormat variable set to null

[evan_kurowski]

Hello Qlik Community,

While working on an earlier thread examining default field formats, something unexpected occurred and I thought I'd ask about it.

With the following script, just before a looped autogenerate, the initialization variable 'DateFormat' is set to null.  When I look at the output in various user-interface areas, the results appear somewhat inconsistent.  What I have questions about, or am not even really sure what to ask is, what is happening with the results?

SET DateFormat=;

For i = 10 to 20
[NULL_DATE_FORMAT]:
LOAD Num(Today() - $(i)) AS F1, Today() AS FIELD_TODAY AUTOGENERATE(1);
NEXT

[swuehl]

Evan,

what I think we are observing is indeed an inconsistent behaviour due to the fact that DateFormat is undefined and that QlikView is not handling a missing format appropriately and apparently handling it differently in different functions (which is quote common in software development ).

You can call this a bug or defect in the software if you want and if you expect QlikView to handle a missing DateFormat.

Just to clarify, any specific reasons you are nulling the DateFormat?

[marcus_sommer]

QlikView struggled with the string-interpretation from those field-values and showed therefore some kind of placeholder but if you used num() or dual() qlikview will show the real values. I think it's quite similar to: Re: Problem with FieldValue

- Marcus

[Gysbert_Wassenaar]

This is definitely buggy behaviour. The value of FIELD_TODAY should not change when the sort order of F1 in the table box is changed. And it does here.

[evan_kurowski]

swuehl wrote:

Evan,

Just to clarify, any specific reasons you are nulling the DateFormat?

Hello swuehl,

Yesterday there was discussion regarding assigning format types to columns, when concatenating multiple sources:  https://community.qlik.com/message/875475#875475‌

In demonstrating how the first format used within a concatenated field assigns it as the final format (and will override subsequent format requests), I was testing a sequence like:

SET DateFormat ='M/D/YYYY';

LOAD Today() AS AS_OF_DATE AUTOGENERATE(1);
LOAD Date(Today(),'MM-DD-YYYY') AS AS_OF_DATE AUTOGENERATE(1);

In the next test, I wanted to see if clearing DateFormat would allow the field [AS_OF_DATE] to pick up the date format specified in the second load of this sequence.  It did not, and that’s when the behaviors were observed.  No apparent practical reasons for assigning DateFormat to null, but doing so does seem to have adverse effects.

QlikView struggled with the string-interpretation from those field-values and showed therefore some kind of placeholder but if you used num() or dual() qlikview will show the real values. I think it's quite similar to: Re: Problem with FieldValue

- Marcus

Hello Marcus,

It does appear similar to Elena888’s ‘FieldValue()’ thread, in that functions which require either or both a textual and numeric component to complete a Dual() evaluation are looking for some way to return a result when not all necessary components are present.

In the case of ‘FieldValue()’, it appears the function says “I cannot fulfill the ‘Display’ side of my Dual() representation requirements, so here is a '?' to indicate there's a problem.”

In the case of  ‘null DateFormat’, the expression appears to resolve by reasoning "I don't have the ‘Display’ & ‘Numeric’ components needed, so let me reach out to other nearby elements to fill the gaps  (Even if that means reaching into an adjacent field or control)"

Gysbert wrote:

This is definitely buggy behaviour. The value of FIELD_TODAY should not change when the sort order of F1 in the table box is changed. And it does here.

Hello Gysbert,

Yes, thank you for pointing this out, I can confirm the same behavior.  Even when making selections in field F1, the Table Box rendering of the field [FIELD_TODAY] is behaving like a chart Last() function. (but inside a table box)

[Gysbert_Wassenaar]

It gets funnier. The value of FIELD_TODAY in sheet objects changes when saving the document and different objects show different (corrupted) values. Did you report this issue in QlikBug‌ already?

Qlik Sense also exhibits this bug. My guess is that some memory corruption is taking place. That in turn suggests at least the possibility of a vulnerability and that just might be exploitable. That's something that needs to be looked at.

[evan_kurowski]

Gysbert Wassenaar wrote:

It gets funnier. The value of FIELD_TODAY in sheet objects changes when saving the document and different objects show different (corrupted) values. Did you report this issue in QlikBug already?

Qlik Sense also exhibits this bug. My guess is that some memory corruption is taking place. That in turn suggests at least the possibility of a vulnerability and that just might be exploitable. That's something that needs to be looked at.

I put in a request to join QlikBug.  If that goes through, and there's a place to enter a new entry, I'll reference this thread.

[evan_kurowski]

Logged @ QlikBug: Inconsistent results when the DateFormat variable set to null

[rbecher]

However this is a bug or missing feature I suggest to run a consistent data format even if the sources have multiple formats. Since we do not have a client site localisation at all for formats (not to mention localized timezone values) you should decide which format to use. In multinational einvironments I would prefer ISO 8601.

[Gysbert_Wassenaar]

Sure, the workaround is clear and easy.

However, this should be looked at imho. Suppose this is a bug and it is possible to create a document that exploits this in some way, be it denial of service or privilige escalation. Stranger things have happened. That's not the kind of document that should be uploaded in for example a Qlik Cloud installation. Better safe then sorry.