Bug #54088 | unknown variable 'default-character-set=latin1' | ||
---|---|---|---|
Submitted: | 30 May 2010 13:18 | Modified: | 31 May 2010 20:09 |
Reporter: | Louis Breda van | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: InnoDB Plugin storage engine | Severity: | S2 (Serious) |
Version: | 1.0.6 | OS: | Windows (VISTA64) |
Assigned to: | CPU Architecture: | Any | |
Tags: | Latin1, unkown variable |
[30 May 2010 13:18]
Louis Breda van
[30 May 2010 15:03]
Louis Breda van
Hello, I just noticed another BUG may be related. When accessing the DB via ODBC (latest ODBC5-release) a significant number of columns do contain ^chinese^ karakters (VISTA64 bit, did not try xp32 bit). This is OK when I query the DB with the MySQL query browser, so there seems to be something wrong in regard to the ODBC-connector <> INNODB DB This is a critical bug / blokking bug for me, since it makes 5.5.3 unusable for me. Sincerely, Louis
[31 May 2010 8:24]
Sveta Smirnova
Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on how to report a bug at http://bugs.mysql.com/how-to-report.php Please see at http://dev.mysql.com/doc/refman/5.5/en/news-5-5-3.html: Incompatible Change: The following obsolete constructs have been removed. Where alternatives are shown, applications should be updated to use them. .... The --default-character-set and --default-collation server options (use --character-set-server and --collation-server). These removed options were listed as deprecated for long time, so this is not surprise MySQL removes them.
[31 May 2010 19:01]
Louis Breda van
Sveta, At first my excuse, I should have read the release notes. I am simply too lazy to read them each release, especially if I do not expect a certain thing to change. I changed it into character-set-server, without deed investications. Or using "Collation" options. I did not add the character-sets-dir="C:/Program Files/MySQL/MySQL Server 5.5/share/charsets" in the client section as well, since that seems to be overdone AND the manual is a bit confusing What ever I still have chinese characters returned over the ODBC on my vista64 server. Which probably has something to do with changes made in 5.5.3. Sincerely, Louis Do not jet
[31 May 2010 20:09]
Louis Breda van
Hello, I just did an extra check in relation with the chinese karakters as show in the MsAccess query browser when connected to the 64 bit 5.5.3. server using ODBC. I noticed another probably related problem. A text field in the MsAccess query is not showing the real text, but in state the text "OLE object" Having seen this, I was intrested to see what data would show up when using Visual Studio 2010 when connected to the same DB over again the ODBC-connector. Surprise (or not :>) the data fetched was correct. So, seeing this I copied the testcode in the MsAccess (2007) database and ... Surprise (or not :>) the data fetched was also correct. So, seeing this :> I used the MsAccess VBA code not to open the MySQL-table but to open the table-link pointing to the MySQL table ==> rubisch So, as it looks now, - Server looks OK - ODBC looks OK when using VS2010 VB-code - ODBC looks OK when using VBA (MsAccess) - MsAccess ODBC-table-link is *NOT* OK when using VBA - MsAccess ODBC-table-link is also *NOT* OK when using the query browser This behavoir did not change after explicitly telling the ODBC-connector that it should use 'latin1' Conclusion at this point is that something changes with 5.5.3 (64 bit) which japanized the the MsAccess ODBC table link. Sincerely, Louis
[1 Jun 2010 8:31]
Tonci Grgin
Louis, please do add some screen shots, output of "show variables like '%char%'" (for your session), show create table/database and so on. It seems obvious to me, Access is interpreting proper data wrongly. Maybe even ODBC trace will help determine what's happening.
[1 Jun 2010 8:43]
Tonci Grgin
This could be related to Bug#54103.