Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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.
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.
@cyg This is expected nature after my 3 months effort in my site.
@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.
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.
@cyg This is expected nature after my 3 months effort in my site.
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.