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.
Hurrican19@stripped 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"
> <ful@stripped> writes:
>
>>Hi,
>>
>>Hurrican19@stripped 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!
>>>
>>>
>>>
>>> Hurrican19@stripped <mailto:Hurrican19@stripped> 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
> <TomM@stripped> writes:
>>>
>>>
>>>>Hurrican19@stripped <mailto:Hurrican19@stripped> 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
/ /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@stripped
/_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
<___/ www.mysql.com
