Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
nsm1234567
Creator II
Creator II

Num# change in behaviour in Qlikview May 2021

Hi there,

I haven't seen any posts or info on this online, but I feel I've come across a very strange new behaviour in the May 2021 version of Qlikview and I'm wondering if anyone else has seen something similar.

For a number of years, I've used functions like the below to create a numeric date number:

=num#(Date(Today(),'YYYYMMDD'),'YYYYMMDD')

I've attached the most basic example of this.  In Qlikview April 2020 SR3, this creates a field whose value is numeric.  You can see this in the simple object in the screenshot below where the date is right-aligned. In May 2021, Qlikview treats this as text.

According to the documentation for num#:  "Num#() converts a text string to a numerical value"

So why is the output of num# no longer a numeric value?  Is this a bug?  It has quite a big impact in some cases as in the load script it messes up joins between tables in some of our applications.  Can someone possibly try to replicate and confirm or let me know if there is something I'm missing here?

Old behaviour.  Number is right-aligned.

nsm1234567_0-1628612502049.png

New behaviour.  Number is left-aligned and appears to now be text?

nsm1234567_1-1628612578686.png

 

 

 

2 Replies
marcus_sommer

I would say that the previous behaviour is rather a bug and the new one is correct because you apply a date-pattern to the numeric conversion. If num#() couldn't convert the content it just returns the content which means it remained a string. I don't know if there are really such adjustments within Qlik newest release to consider such things more strict as before or if it's more accidentally caused from different settings in Qlik and within the OS - there might be changes, too.

Nevertheless I suggest to change your logic to something like:

set x = "num#(text(date($1,'YYYYMMDD')))";

and calling this per parameter-variable customized function like:

$(x(MyDateField)) as xyz

within the loads. To replace it everywhere is surely not the nicest job but with ctrl + h/c/v it shouldn't take very long and is probably faster as searching for the differences between the releases and/or for any workarounds.

- Marcus

Irwin
Contributor
Contributor

If you've tried basic troubleshooting steps for the issue(s) you're encountering and these don’t help, please be kind to submit your issue to the Feedback Hub. This is the best approach to get your feedback properly channeled to the Engineering Team, and we can also gather additional details and information about your issue so that we can figure out what’s causing it and address it.

 

 

greatpeople