TD 6.3 <- utf8 -> MySql

[Johann]

Hello,

I face following problem with a MySql connection: The DB longtext columns are utf8, the odbc dirver is also an utf8 driver (on WIn 8.1). When selecting the content from the longtext in TD 6.3 I get Chinese characters/pictograms, trying to convert them with SalStrToWideChar() to UTF8, ANSI, etc. produces only trash. The same with SalStrToMultibyte() - no chance to get something usable
BUT
When I use the SqlTalk from TD 2.1 and make a select via the same odbc definition, what a surprise everything is ok!

I thought, TD 6.3 should be able to represent UTF8 chars.
Any idea, what is going wrong?

Regards
Hans

[frevelundfey]

Hi Hans,
if you fetch data into a String or LongString bindvar it's representation is always converted to UTF16 (TD63) regardless of the representation in the database.
If you fetch it to a Binary datatype then data is not converted.

Maybe TD "thinks" that the data is stored as UTF16 and does not convert it.
I see two reasons for that:
1) Maybe you use SqlSetLongBindDatatype with DT_Binary (23) - then it's your fault
2) There is some bug in handling datatype-conversion between ODBC and TD.

You might try to fetch the data into a Binary variable.
Then convert it to a String with

Code: Select all

Set sValue = SalBinaryToString( binValue, ENC_UTF8 )

Regards Thomas

[Johann]

Hi Thomas,

that was it. I defined the column as binary and worked as you suggested.

A long string, coming from a DB as utf8 (setting in DB and also in ODBC connection) into TD, it is automatically converted to utf16. Why do I not get the original string back, when I convert the uft16 to utf8 with SalStrToWideChar()?

Regards
Johann

[frevelundfey]

Hi Johan,
how do you find out that SalStrToWideChar() does a wrong conversion?
The reason I ask is because I find it not easy to see the internals of a Unicode-String in Gupta.
Do you use SalStrLopAscii()?

Regards Thomas

[Johann]

Hi THomas,
I knew before what the result should be....
Regards
Johann