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]
