Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Join us in Bucharest on Sept 18th for Qlik's AI Reality Tour! Register Now
cancel
Showing results for 
Search instead for 
Did you mean: 
cyg
Contributor II
Contributor II

Stronger Data Typing

The environment I'm working in has recently been upgraded the Qlik Sense server to May 2023 version. After upgrading, Qlik becomes stricter with its data typing between text and numbers. FYI, database wise, we're on Oracle.

There are 2 issues I found

1. In the load script. We have a fact table with a year_month (eg. 202402) column with a varchar data type. While the month dimension, also has a year_month column with a number data type. If I were to query the records from the fact first and query the month dimension after, filtering the records with a WHERE EXISTS(year_month) in the load script, it will return 0 results from the month dimension. The work around that works, I had to cast both columns in the 2 tables to the same data type.

Do also note that, connecting to Oracle via the QV Oracle ODBC causes this issue but connecting to the same database via ODBC or OLE DB, works fine.

2. In the chart. I query a column with a varchar data type, called severity_code. It contains records that are numeric and alphanumeric. eg. of the values in the column 1, 2, 3, NA, UNK. When I check the data type from the model viewer, the column is a $ascii$text. 

In the dashboard, I created a button to filter on the records when someone clicks on it, where it will filter for 1,2,3,NA only.

cyg_1-1708406748874.png

But when I click on the button, only NA is selected. The values which are purely numeric are not selected.

When I create 2 inline tables:

TEST:
LOAD TEXT(COL) as COL
INLINE [
COL
1
2
3
NA
UNK
];

TEST2:
LOAD COL2
INLINE [
COL2
1
2
3
NA
UNK
];

The button would work for COL2 (which is not cast as text) but COL behaves like the severity_code issue above.

Questions, is this a new feature in the new version? A bug? Or is there a server setting that has changed?

For issue #2, is there a work around for it? Thanks.

Labels (7)
1 Solution

Accepted Solutions
Anil_Babu_Samineni

@cyg This is expected nature after my 3 months effort in my site. 

Best Anil, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful

View solution in original post

4 Replies
Anil_Babu_Samineni

@cyg If I am not wrong the connector you use is Native (Simba provider), I guess the connector also upgraded. For my situation if that helps

1) I have very bad performance using ODBC and OLEDB, due to the fact I change to Native connector. With this the developer must do some tweaks inside (Ex, Data types, Format of date, Max() etc.)

2) Please verify if the connector version also changed? Hope your case is not #1, because this is just upgrade.

Best Anil, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful
cyg
Contributor II
Contributor II
Author

Yes, the connector has also been upgraded. So it is an expected functionality with the new connector?

And like you, the reason why I did not end up using ODBC/OLEDB is because of performance.

Anil_Babu_Samineni

@cyg This is expected nature after my 3 months effort in my site. 

Best Anil, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful
Or
MVP
MVP

I can verify that I encountered the same behavior in a handful of cases. Using Text() or num()/num#() as appropriate or casting the data within the SQL statement both worked as a resolution. Incidentally, this was also the case in older versions, but it seems to be a little more finicky than it was before in May 2023.