MySQL Bugs: #32596: SET NAMES should be disallowed

Bug #32596	SET NAMES should be disallowed
Submitted:	21 Nov 2007 20:03	Modified:	3 Dec 2007 7:29
Reporter:	Jim Winstead	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S4 (Feature request)
Version:	5.1	OS:	Any
Assigned to:	Jim Winstead	CPU Architecture:	Any
Tags:	SET NAMES

Description:
SET NAMES causes problems for C/ODBC 5.1, because it causes the client library to lose track of what the client character set is, and the driver expects character_set_results to be NULL.

How to repeat:
Issue SET NAMES as a query, or use it as the initial statement.

Suggested fix:
Disallow SET NAMES within the driver.

Patch to disallow 'SET NAMES'

Attachment: bug32596.diff (text/plain), 4.17 KiB.

this was committed and will be in 5.1.1.

A note has been added to the 5.1.1 changelog: 

The SET NAMES statement has been disabled because it causes problems in the ODBC driver when determining the current client character set.

i hate this !why you XX Disallow 'Set Names'? i need it , now i can't get right charaters ,i can get only '?' , i have to change to v3.5,i hate 5.1

I agree. I have used SET NAMES a bunch of places, now my program stops with an error saying: "the driver does not allow SET NAMES". Now I have replaced SET NAMES with "SET CHARACTER SET", but when I looked the page again I see these: <?>
everywhere where I had a special, non standard character on my language.
Now I am going back to the good old 3.1 ODBC Connector to see if I can fix the problem...

SET NAMES should be used with caution and usually means you have mess in your database. Please review http://forge.mysql.com/wiki/How_to_Use_Charsets_and_Collations_Properly and other documentation regarding proper usage of charsets and collations.

Note on "3.51/5.1": All of the connectors run, as far as charsets and collations are concerned, in "debug" or, how I like to call it, "autodetect" mode, setting session encoding to NULL. In this case, any misconfiguration will inevitably lead to wrong characters displayed. Instead of calling for dangerous functions, do check your data.

Finally, c/ODBC 3.51 is single-byte charset driver. There is no support for "wide" (W) ODBC functions in it at all. So, if your code is written for such charsets and your data is in that form, you should be better off with 3.51 which does not mean 5.1 is not usable or faulty in any way.