Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello, I'm loading tables from a SQL table though an ODBC connection and I'm getting this error on one of the table loads.
QVX_UNEXPECTED_END_OF_DATA: SQL##f - SqlState: S1000, ErrorCode: 50310, ErrorMsg: [][Support] (50310) Unrecognized ICU conversion error.
The driver I am using encodes the data as UTF-8 wheras my dataset is in Windows CP1252.
Is there any way to define the character set in QlikView for ODBC connections as there is for Load functions?
Or a config where QLikView will not throw an exception when encountered with a special character? (Like in other tools where the non-UTF-8) character is displayed as an unknown character but the query doesn't crash.
did you search on google / community??
see following similar query on community.
ErrorCode: 50310 loading from ODBC connected database
Regards
Yes, but we want a solution where we do not have to change our dataset.
You should set up the ODBC configuration in the ODBC driver you are using on the Qlik computer to use UTF-8. There is really not many good reasons (if any) not to use UTF-8 nowadays instead of the old antiquated Windows CP1252.
QlikView doesn't support any way to stop the driver from throwing an exception. If you force QlikView by using using ERRORMODE=0 to ignore the exception caused by the driver the entire table in question will not be loaded - not just the offending row.
Even now, without using the ERRORMODE=0, the entire table is not loaded. The query fails with the mentioned exception and no data is retrieved.
From our observations, it is not the driver throwing this exception but QLikView. The same query, using the same dataset passes on other tools.
Also, is there a specific ODBC version that is compatible for QLikView?
What kind of ODBC-driver are you using? From which vendor and which version? Is it one of the Qlik provided ODBC-drivers?
Qlik does not certify third party drivers but the documentation state which level of ODBC conformance that needs to be in the ODBC-driver I believe.