Hello.
>But anyway, the source *IS* latin1, so maybe this shouldn't be a > problem anyway? In theory if the source contains only characters from latin1 set there shouldn't be any problems, but are you sure that you're inserting latin1 characters? What is your locale settings? If you can, temporary switch it to utf8. Force character_set_connection, character_set_client, character_set_results variables to have 'utf8' value. Change the default character set of all fields to utf8 (ALTER TABLE can do this or just create a new table). Check if you're able to store and get correct data in mysql command line client. > Thanks for the reply, by the way :) I also read your posts to the list with great pleasure :) Daniel Kasak wrote: > Gleb Paharenko wrote: > >> Hello. >> >> I've been able to insert Russian characters (utf8) through the >> QueryBrowser under Linux (FC4). Please, could you provide CREATE >> statement for you table >> > CREATE TABLE `WebNewsPostings` ( > `PRID` mediumint(8) unsigned NOT NULL auto_increment, > `MyStamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update > CURRENT_TIMESTAMP, > `DateDay` tinyint(3) unsigned NOT NULL default '0', > `DateMonth` tinyint(3) unsigned NOT NULL default '0', > `DateYear` mediumint(8) unsigned NOT NULL default '0', > `CopyTitle` varchar(255) character set latin1 NOT NULL default '', > `CopyMain` mediumtext character set latin1 NOT NULL, > `Image` varchar(50) character set latin1 default '', > `Language` tinyint(3) unsigned NOT NULL default '0', > PRIMARY KEY (`PRID`) > ) ENGINE=MyISAM DEFAULT CHARSET=utf8 > > I don't know what those individual 'character set latin1' bits are. I > haven't been messing with per-field character sets - I've just been > using mysql-administrator to change the character set for the entire > table. But anyway, the source *IS* latin1, so maybe this shouldn't be a > problem anyway? > >> and output of: >> show variables like '%char%'; >> > mysql> show variables like '%char%'; > +--------------------------+----------------------------+ > | Variable_name | Value | > +--------------------------+----------------------------+ > | character_set_client | latin1 | > | character_set_connection | latin1 | > | character_set_database | latin1 | > | character_set_results | latin1 | > | character_set_server | latin1 | > | character_set_system | utf8 | > | character_sets_dir | /usr/share/mysql/charsets/ | > +--------------------------+----------------------------+ > 7 rows in set (0.00 sec) > >> >> As far as I know, QueryBrowser invokes SET NAMES 'utf8' by default. >> And the only way to force it to use your connection character sets is to >> run a transaction. Are characters that you're pasting into QueryBrowser >> displayed correctly in the query tab? >> > Yes. They display correctly - both in query browser AND in my Perl Gtk2 > app. What's more, when I inspect the binary query log, the same sequence > of reverse-coloured characters is used to represent the characters that > are giving problems. Which ever method I use to get the data in ( query > browser / in-house Perl Gtk2 app ), the data *looks* perfect when I > paste it in, but when I return to look at it later it's corrupted. > > Thanks for the reply, by the way :) > > Dan > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
