The MySQL documentation (4.6.1) says:
> You can change the character set with the --default-character-set option
> when you start the server. The character sets available depend on the
> --with-charset=charset and --with-extra-charsets= list-of-charset | complex
> | all options to configure, and the character set configuration files listed
> in `SHAREDIR/charsets/Index'. See section 2.3.3 Typical configure Options.
>
> If you change the character set when running MySQL (which may also change the
> sort order), you must run myisamchk -r -q on all tables. Otherwise, your
> indexes may not be ordered correctly.
I have a MySQL server with databases that need to begin supporting
japanese characters. Per the advice cited above, I've shut it down, restarted
it with '--with charset=sjis', and run 'myisamchk -r -q' on all tables. All
seems well enough. But when I run 'myisamchk -dvv <tablename>', the
'Character Set' line in the output indicates that the character set for tables
created before I added '--with charset=sjis' to the safe_mysqld startup script
is still 'latin1', whereas for newly created tables, myisamchk reports the
character set is 'sjis'. The fact that the output is different for tables
created before and after the change was made suggests to me that I'm over-
looking something.
So my suspicion is that I may need to, for all existing tables, dump
the data in each table to disk, drop and recreate the table, and then reload
the data, in order to guarantee that (for instance) a varchar(80) in a pre-
existing table will really be able to hold 80 (potentially multibyte) japanese
characters. Is this actually the case, and if so, is it discussed in the
docs anywhere? I've spent a couple hours doing web/list searches and haven't
uncovered any references to anything like this, but would think that it must
have come up before for someone. When the documentation says, 'You can change
the character set with the --default-character-set option', is it speaking just
of the character set used in client/server communication -- as opposed to the
encoding scheme used when physically storing the data? Is 'myisamchk -r -q'
only making corrections related to collation as opposed to changes related to
allocation? Or is MySQL smart enough that, after creating tables, you can
change character sets on the fly, patch up collation-related issues with
myisamchk, and continue happily along? If this is the case, why the
discrepancy in 'imyisamchk -dvv' output for pre-existing vs. post-
--default-character-set=sjis tables?
Disclaimer: I'm a person with a Sybase background, new to MySQL, so
it's possible my assumptions are all askew.
Mark Stantz
[EMAIL PROTECTED]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
