Bug #54088 unknown variable 'default-character-set=latin1'

Description:
Hello,

I just updated the MySQL server version 5.5.2 towards 5.5.3 on my VISTA64 machine. After doing so the server refused to start. 

Note that 5.5.3 does run without noticed problems / or adjustments on my xp32 cpu !

Analysing the server log showed a quite unexpected error message:

100530 14:21:49 [ERROR] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: unknown variable 'default-character-set=latin1'
100530 14:21:49 [ERROR] Aborting

I could pursuade the server to run by removing the default character setting from the ini file :> (note that the same setting is still active on my xp32 system) !

# The default character set that will be used when a new schema or table is
# created and no character set is defined
#@@@@@@@@ probleem 5.5.3 default-character-set=latin1

Hope this helps.

Below a little bit bigger part of the error log.

Sincerely,

Louis

How to repeat:
***** Normal My.ini ******

00530 14:21:48 [Note] Buffered information: Performance schema disabled (reason: start parameters).

100530 14:21:49 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
100530 14:21:49  InnoDB: highest supported file format is Barracuda.
100530 14:21:49 InnoDB Plugin 1.0.6 started; log sequence number 63381777843
100530 14:21:49 [ERROR] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: unknown variable 'default-character-set=latin1'
100530 14:21:49 [ERROR] Aborting

100530 14:21:49  InnoDB: Starting shutdown...
100530 14:21:51  InnoDB: Shutdown completed; log sequence number 63381777853
100530 14:21:51 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Shutdown complete

100530 14:23:43 [Note] Buffered information: Performance schema disabled (reason: start parameters).

***** After my.ini change ****

100530 14:42:40 [Note] Buffered information: Performance schema disabled (reason: start parameters).

100530 14:42:40 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
100530 14:42:40  InnoDB: highest supported file format is Barracuda.
100530 14:42:41 InnoDB Plugin 1.0.6 started; log sequence number 63381777883
100530 14:42:41 [Note] Event Scheduler: Loaded 0 events
100530 14:42:41 [Note] C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: ready for connections.
Version: '5.5.3-m3-community'  socket: ''  port: 3306  MySQL Community Server (GPL)

Suggested fix:
I do not know what is wrong, the My.ini setting is a quite normal and valid setting I think. Probably something else is wrong.

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

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.

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

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

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.

This could be related to Bug#54103.