Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

v10 ODBC date/time bug?

Hi all,

I've just upgraded to v10 and have experienced a problem with a date & time field. It only seems to happen when connecting to source data via ODBC. My date & time field Timestamp is in the format YYYY-MM-DD hh:mm:ss.

In v9 SR5, I used date(left(Timestamp, 10), 'DD/MM/YYYY') to extract the date part with no decimals. But in v10, this doesn't work. Timestamp is formatted as DD/MM/YYYY but the decimals are not excluded so multiple instances of the date appear.

There are a number of other options e.g. date(floor(Timestamp), 'DD/MM/YYYY') so I have overcome the problem but it does seem like strange behaviour to me.

Has anyone else experienced this?

4 Replies
Not applicable
Author

APS,

I'm experiencing a similar issue coming from v 8.5 to v10 when I create a concatenated key from an ODBC source (DB2).

v8.5 handles the date fields on the ODBC source as strings -- so '2010-10-01' on the database is stored in QlikView as 2010-10-01.

v10 appears to interpret the date on the ODBC source as a number: 2010-10-01 on the database is stored/handled by QV as 40452.

this is serious issue with the 50+ incremental load scripts we employ because, as we load the daily incremental data we concatenate to that incremental data the historical QVD using WHERE NOT EXISTS (Concat_Key_Field). This Concat_Key_Field in the historical QVD (created over the years with v8.5) has dates as strings (e.g. 123_456_2010-10-01) whereas the incremental data being loaded by v10 has numeric dates (e.g. 123_456_40452). This means that, if I had to fix some historical data and wanted to re-pull a few dates' worth of data from DB2, I cannot use the incremental logic WHERE NOT EXISTS because I will have two distinct Concat_Key_Field values for the same record.

I am not sure what to do about this short of reprocessing all of our historical data files to have numeric dates. PAINFUL and Risky!

Any ideas on how to work around this?

Thanks,
Tyler

Not applicable
Author

Hello,

I dont remembre where I read this, but I think when you try to upgrade from 8.5 to 10 directly, then there are a lot of other problems to and QT hence suggests to upgrade first to 9 and then to V10 and I think its good. When you have a license for 10 I think you can even use 9 or you may have to contact QT mail and check what they have to say. Personally I never worked on any upgrade projects but I am really looking forward to in the future....

Mama

Not applicable
Author

I would not be too excited to upgrade.

Can you tell me where you read in the documentation about specific issues which will arise when upgrading from v85?

Thanks!

Tyler

Not applicable
Author

Hi Tyler,

I'm not sure that upgrading to v9 first will make any difference. I upgraded from v9 SR2 to v10 and it was only then that I experienced the problem. In the end, I used the floor method described above but it did require a full reload of all historical qvds.

Perhaps QlikTech are aware of this and have fixed it in v10 SR2 but I don't know.

Regards,

APS