Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Not a Bug
-
2.0.13
-
None
-
None
-
Client: any Windows. Server: MariaDB version 10.0.28 on Fedora
Description
I have a small programm that runs fine with Maria ODBC 1.0.6. On entering some text it selects data from the server and displays it. With Maria ODBC 2.0.13 I do have a problem with special german characters (ö,ä,ü....).
If the search string contains those characters nothing is found. You find the select in the 1st attached screenshot (was too lazy to write it down 
The problem seems to be only in the select. Cause the data returned (if you do a select without special chars) does contain those special chars and they are correctly shown in the program.
The 2nd screenshot attached shows the situation with version 1.x of the ODBC connector. I searched for "mö" and got my results.
The 3rd screenshot shows the situation with version 2.0.13. Same program, same Server. I also searched for "mö" but got no results.
The 4th screenshot is also with version 2.0.13 but I searched for someting not containing "ö" to show that data containing "ö" is selected and normally displayed.
The program itself doesn't use WCHAR. Just plain char which I think is ANSI (I'm no expert on character sets and still more and more confused the more I know about it
I can just state that with no component changed but the ODBC connector there's a different behaviour.
Attachments
Activity
Sooo. Sorry for the late reply but I had a (boooooring - don't tell anyone) meeting this morning
Yes, setting the character set to cp1250 solved it! Thank you!
The problem with 2.0.13 is only when you set the character set to "nothing" as I did with 1.0.6. There it works that way.
Don't know if you still need the informations you requested (as for me it is solved .
If yes: I stripped down my program to get rid of everything not needed to get a clearer view on the problem.
So it now does just the plain query and shows the results in the client window.
You can see the results in the files "Output-1.0.6.jpg" and "Output-2.0.13.jpg". Only difference is the version of the ODBC connector.
I also attached the source files of the program (odbctest.c and stdafx.h everything else is Visual Studio 2012 default) so that you can see what I'm doing. Everything relevant is in the WM_USER message.
I also attached some additional files.
create_table_support.txt contains the show create table.
SQL-1.0.6.LOG is the log of the working query with Version 1.0.6 of the ODBC connector.
SQL-2.0.13.LOG ist the log of the query that doesn't return data with the 2.0.6 Version.
query_with_webmin.jpg shows the query directly run on the server (using webmin).
That wasn't any "late reply" 
Thanks! Now I am even feel a little bit ashamed, since I requested you all possible info, that could help to pin down the problem, and which is all together is even slightly an overkill. And you provided it all! While setting charset helped.
I think we can close the issue, since setting charset helped. It's a bit strange why such a difference between 1.0.6 and 2.0.13. I glanced over the code, and logic around connection charset seems to have stayed the same.
Please, find more bugs - you are one of my favorite bug reporters by far
Thanks for your bug report!
Would it be also possible to provide "show create table" for involved tables?
And how do you send your query? Assemble it with you search string and send with SQLExecDirect or bind parameters? Or you don't use ODBC API directly? The best thing would be to provide ODBC trace file for the issue.
And could you also try to set character set to something like win1252 or win1250? Or anything you see in your "show create table" queries.
Even if you don't use WCHAR directly, it is still used by ODBC behind the scene. i.e. all ansi ODBC API calls are mapped to Unicode calls, and (several) charset conversions are done. But since you say it worked with 1.0.6, I really wonder what could have been broken since then.