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:
None 
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
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.
[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.