The bug was updated successfully. The following people were notified: the MySQL developers, the bug reporter, the assigned developer, and nobody else.
Bug #8420 | charset bug | ||
---|---|---|---|
Submitted: | 10 Feb 2005 16:58 | Modified: | 23 Jun 2005 13:35 |
Reporter: | [ name withheld ] | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 4.1.x | OS: | Windows (Win32) |
Assigned to: | CPU Architecture: | Any |
[10 Feb 2005 16:58]
[ name withheld ]
[12 Feb 2005 4:10]
[ name withheld ]
I have addidional information regarding situation with charsets. First: Temporary solution is to add attribute flag="primary" to <collation name="cp1251_bulgarian_ci" id="14"> in section <charset name="cp1251">. It's prevents MySQL from trying set collation cp1251_general_ci as primary. There is no such collation as: cp1251_general_ci (id 51) cp1251_ukrainian_ci (id 23) cp1251_bin (id 50) cp1251_general_cs (id 52). Second: SHOW COLLATION query result shows that no one of cp1251 collation is not compiled (including cp1251_bulgarian_ci). Nevertheless collation cp1251_bulgarian_ci works whereas other collation if set as primary cause error. Moreover if any of this collations excluding cp1251_bulgarian_ci is set as primary client connects current character set for client (mysql.exe or any front end or php) became latin1 and collation latin1_swedish_ci even SET NAMES CP1251 SET COLLATION_CONNECTION=CP1251_GENERAL_CI queries is executed. Third: libmySQL.dll is client library and if it used with mySQL front-end applications such as EMS MySQL manager, MySQL-Front client character set became latin1 and collation latin1_swedish_ci even mysql configuration file [client] and [server] sections has character-sets-dir="[my path to dir]" default-character-set=cp1251 ...or... SET NAMES CP1251 SET COLLATION_CONNECTION=CP1251_GENERAL_CI queries is executed. And last: If field in table is set to CP1251_GENERAL_CI collation all database became unreadable for mysql! All described cause loosing data in all tables! Records in cp1251 became like "???? ???? ???"
[12 Feb 2005 4:16]
[ name withheld ]
caused data loss
[17 Feb 2005 14:39]
[ name withheld ]
just tested on FreeBSD - MySQL 4.1.9 compiled with all charsets. same as on win32
[20 Mar 2005 4:43]
Michael Kostenko
It is not the server bug in Windows. It is ODBC driver v3.5.11 bug. V3.5.9 works nice! You have some problems with new user library (4.1.x). All strings in cp1251 become like "?????????" in databse.
[20 Mar 2005 13:55]
[ name withheld ]
Michael Kostenko wrote: It is not the server bug in Windows. It is ODBC driver v3.5.11 bug. V3.5.9 works nice! You have some problems with new user library (4.1.x). All strings in cp1251 become like "?????????" in databse. There is no ODBC, because PHP does not use ODBC in mysql_* function. I have discovered that problem in PHP mysql library. Windows version of PHP 4.x.x compiled with old libmysqlclient - 3.xx.xx. Moreover, it has hardcoded path to mysql charset dir.
[23 May 2005 13:35]
MySQL Verification Team
Are you tested using PHP 5 ?
[23 Jun 2005 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".