Hello, thanks for helping! Here is the output of the requested statements on live database:
SHOW CREATE TABLE avatardata; | customavatar | CREATE TABLE `customavatar` ( `userid` int(10) unsigned NOT NULL default '0', `avatardata` mediumtext NOT NULL, `dateline` int(10) unsigned NOT NULL default '0', `filename` varchar(100) NOT NULL default '', PRIMARY KEY (`userid`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | SHOW CREATE DATABASE 'put the name of the avatar database'; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''customavatar'' at line 1 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/local/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------------+ Here is my my.cnf file [Removed commented out sections]: [client] #password = your_password port = 3306 socket = /var/lib/mysql/mysql.sock # Here follows entries for some specific programs # The MySQL server [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock skip-locking key_buffer = 16M max_allowed_packet = 1M table_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K myisam_sort_buffer_size = 8M datadir=/var/lib/mysql old-passwords log-bin server-id = 1 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash # Remove the next comment character if you are not familiar with SQL #safe-updates [isamchk] key_buffer = 20M sort_buffer_size = 20M read_buffer = 2M write_buffer = 2M [myisamchk] key_buffer = 20M sort_buffer_size = 20M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout [mysql.server] user=mysql basedir=/var/lib [safe_mysqld] err-log=/var/log/mysqld.log In a message dated 1/8/2005 10:52:13 AM Eastern Standard Time, Gleb Paharenko <[EMAIL PROTECTED]> writes: >Hello. > >mysqldump usually produced > SET NAMES utf8 >at the begining of the dump file. The clues may be in this. Send us >the output of such statements: > SHOW CREATE TABLE avatardata; > SHOW CREATE DATABASE 'put the name of the avatar database'; > SHOW VARIABLES LIKE '%char%'; >and your my.cnf file. Use --default-character-set=latin1 command line option >for mysqldump. > >[EMAIL PROTECTED] wrote: >> Hi Dr. >> The avatars still show fine on 4.18a -- but the problem occurs when I >> actually do a dump and reimport the dump file. That's when something goes >> array.. Kinda weird if you ask me.. I wish that vBulletin wouldn't actually >> hard code the binary in a table, lol.. It's got me totally baffled! :) >> >> >> In a message dated 1/7/2005 4:02:04 AM Eastern Standard Time, "Dr. Frank >> Ullrich" <[EMAIL PROTECTED]> writes: >> >>>Hi, >>> >>>[EMAIL PROTECTED] schrieb: >>> >>>> Hi Tom, >>>> Thanks for the reply! I show the following information for my DB, >>>> and shows the same for both the 3.23 DB And the 4.18a DB >>>> >>>> Field ---- Type ---- Collation >>>> avatardata ---- mediumtext ---- latin1_swedish_ci >>>> >>>> I pasted a data table from the bad avatar and the good avatar >>>> to a file differential program, there was no differential at all >>>> that the system found.. >>> >>>that seems to point towards a client issue. >>>Which client do you use to look at the atachments (I think I have heard >>>about problems with php and 4.1.x on this list recently)? >>> >>>As a further test I would suggest that you take the data table (.myd >>>file?) from the 4.1.8 db and copy it into a __test__ 3.23 db replacing >>>the data table there (it's myisam isn't it?). See if the avatars are ok >>>when you read them from the 3.23 db. >>> >>>Regards, >>> Frank. >>> >>> >>>> >>>> I'm not too sure where or what to do to change this information? Do you >>>> mean >>>> that I recompile MySQL using different ./configure commands? >>>> >>>> Thanks Tom! >>>> >>>> >>>> >>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote on Thursday, January >>>> 06, 2005 4:57 PM: >>>> >>>> >>>>>Sorry, forgot the attachments. These are the same exact two >>>>>avatars from the same user, using my 3.23 backup, for the >>>>>good avatar, then the 4.18 bad avatar >>>> >>>> >>>> Looks like a character set issue - what's the column type, BLOB or TEXT or >>>> something in between? >>>> >>>> This could be due to the server converting UTF-8 into a different character >>>> set. Characters such as 0x8F (143 decimal) and 0x8D are being converted >>>> into >>>> 0x3F, which is "?" and often indicates that the character does not exist in >>>> the target collation. Basically, MySQL is treating the content as text, and >>>> replacing characters which it doesn't understand with "?". Try using a >>>> different collation or character set, and importing again? >>>> >>>> Unfortunately, the conversion is not reversible - a set of characters have >>>> been replaced with a single character, so although the image is the same >>>> binary size, some of the data has been permanently lost unless you can >>>> restore from the backup. >>>> >>>> cheers, >>>> >>>> Tom >>>> >>>> >>>> In a message dated 1/6/2005 12:48:28 PM Eastern Standard Time, Tom >>>> Molesworth <[EMAIL PROTECTED]> writes: >>>> >>>> >>>>>[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote on Thursday, January >>>>>06, 2005 4:57 PM: >>>>> >>>>> >>>>>>Sorry, forgot the attachments. These are the same exact two >>>>>>avatars from the same user, using my 3.23 backup, for the >>>>>>good avatar, then the 4.18 bad avatar >>>>> >>>>>Looks like a character set issue - what's the column type, BLOB or TEXT or >>>>>something in between? >>>>> >>>>>This could be due to the server converting UTF-8 into a different character >>>>>set. Characters such as 0x8F (143 decimal) and 0x8D are being converted >>>>>into >>>>>0x3F, which is "?" and often indicates that the character does not exist in >>>>>the target collation. Basically, MySQL is treating the content as text, and >>>>>replacing characters which it doesn't understand with "?". Try using a >>>>>different collation or character set, and importing again? >>>>> >>>>>Unfortunately, the conversion is not reversible - a set of characters have >>>>>been replaced with a single character, so although the image is the same >>>>>binary size, some of the data has been permanently lost unless you can >>>>>restore from the backup. >>>>> >>>>>cheers, >>>>> >>>>>Tom >>>>> >>>>> > >-- >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] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
