Qlik Community

Connectivity & Data Prep

Discussion board where members can learn more about Qlik Sense Data Connectivity.

Announcements
Customer & Partners, DEC. 9, 11 AM ET: Qlik Product & Strategy Roadmap Session: Data Analytics REGISTER NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Architect
Creator
Creator

multi-byte character error

In my project, I have encountered one problem while loading data in QV app from the ODBC connection.
 
 Initially, I tried to connect with DB using below connection string,-->
"ODBC CONNECT TO [rt70-dareo;DBQ=rt70.XYZ.com] (XUserId is OTfWFMSLZeGBA, XPassword is BFDeDXFGUDdSXTJORBdIXK);" but having multibyte charecter error.
 
That is why I tried the below process.-->
 
"ODBC CONNECT TO [rt70-dareo;DBQ=rt70.XYZ.com] (XUserId is OTfWFMSLZeGBA, XPassword is BFDeDXFGUDdSXTJORBdIXK,CodePage is 65001);"--UTF-8
also I have used
"ODBC CONNECT TO [rt70-dareo;DBQ=rt70.XYZ.com] (XUserId is OTfWFMSLZeGBA, XPassword is BFDeDXFGUDdSXTJORBdIXK,CodePage is 20127);"--US-ASCII
 
Though, having the same error message.-->
 
"Error: QVX_UNEXPECTED_END_OF_DATA: SQL##f - SqlState: S1000, ErrorCode: 29275, ErrorMsg: [Oracle][ODBC][Ora]ORA-29275: partial multibyte character"
 
When investigating the data in Oracle that causes this error it is this string :
"ÂBATCH"
 
Most probably the “” is the reason behind the issue.
 
I am using qlik version 12.30.20000.0.

 
The current NLS character set in our Data Base is; AL16UTF16.
 
What our Client wants is to make the changes in QlikView end only to resolve the issue, without modifying the D
 
If you have any solution in your mind please let me know.
Labels (4)
1 Solution

Accepted Solutions
Architect
Creator
Creator
Author

The issue got resolved by the below process I followed in Oracle 19c.

"maint.audit_0806test_tbr" was the table with corrupt data.

I did the below conversion on the responsible columns –

update maint.audit_0806test_tbr set OBJECT_SCHEMA=convert(OBJECT_SCHEMA,'US7ASCII','WE8ISO8859P1');

update maint.audit_0806test_tbr set OBJECT_NAME=convert(OBJECT_NAME,'US7ASCII','WE8ISO8859P1');

COMMIT;

While using the updated table maint.audit_0806test_tbr in QlikView.
Able to reload the data in QV from the temp table successfully.

 

View solution in original post

11 Replies
marcus_sommer
MVP & Luminary
MVP & Luminary

I would say not Qlik caused the issue else your used driver which might not able to handle this char respectively not the charset respectively it's not properly defined. I think your specified codepages didn't really match utf-16.

- Marcus

Architect
Creator
Creator
Author

Hi Marcus,

yes, you are right, while fetching data from ODBC connection I am not sure if Codepage is able to convert the UTF-16.

Can you help with the value of UTF-16 in Codepage?

Another question, can I use Codepage in the ODBC connection? Or there is another way for it?

 

marcus_sommer
MVP & Luminary
MVP & Luminary

I don't know if you could specify any codepage within your driver and if which ones (there might be further dependencies, for example for certain libraries to handle multibyte characters). If I had looked right on the following links the codepage 12000 seems the one for utf-16:

https://en.wikipedia.org/wiki/UTF-16 

https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers 

I assume that Qlik isn't the only tool which accessed your db. Therefore take a look which other tools or databases fetch also data from there and which driver with which specs they use for it - and then try to adopt it.

- Marcus

 

Architect
Creator
Creator
Author

HI

Got your point. But I have a doubt regarding it.

Is there no way QlikView can show Multibyte Char from DB, connecting through ODBC?

And What I understand, Chinese and Japanese characters are mostly Multibyte, In that case how Qlik manages to show them inside report?

@marcus_sommer 

@tresesco 
@Mauritz_SA 

@kaushiknsolanki

marcus_sommer
MVP & Luminary
MVP & Luminary

Like above already mentioned it's not a Qlik problem (Qlik doesn't execute any sql-query else only transferred the statement to the driver who transferred to the db which executes the query and returned the results per driver back to Qlik) else your used driver couldn't handle these multibyte-chars respectively isn't properly configured for it.

- Marcus

cwolf
Creator III
Creator III

In most cases this error is caused by an invisible character which is not convertible or by a damaged record.

You can try to load the column with convert() function:

convert(column_name,'utf8') as new_column_name,

kaushiknsolanki

Which ODBC connector you are using?

Is it standalone driver you have installed or the one from the Qlik's Package?

 

Regards,
Kaushik
If reply is satisfactory, please "Like" the post.
If reply is solution, please mark as "Correct".
Architect
Creator
Creator
Author

HI Kaushik,

I am using ODBC connection from Qlik Package only.

Brett_Bleess
Support (Former)
Support (Former)

Given you are using our connector, the first place I would start is reviewing the Help doc to be sure you have followed the guidance there.  I am in agreement with Marcus regarding his comments, I do not think we can fix the issue here, you may have to use the actual Oracle Client driver instead of ours if you need the additional functionality and submit an enhancement request for our driver in the Community Ideas area.

Help Doc:
https://help.qlik.com/en-US/connectors/Subsystems/ODBC_connector_help/Content/Connectors_ODBC/Oracle...

Ideas area on Community:
https://community.qlik.com/t5/Ideas/idb-p/qlik-ideas

There are two sub topics on the Help like just FYI, would review both of those.  The only other thing of which I can think is in order to process the Multi-byte correctly in the connector, you may need to be running that language version of things in order to have access to that processing, just a hunch though.  The other thing I am going to do after I post this is move the thread to the Connectors area too, as that is the better place for this given the latest information, one of the engineers or product team may have a look at things at that point and shed some further light upon things potentially.

Regards,
Brett

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.