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 >>> >>>-- >>>MySQL General Mailing List >>>For list archives: http://lists.mysql.com/mysql >>>To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] >>> >>> >> >> > >-- >Dr. Frank Ullrich, DBA Netzwerkadministration >Heise Zeitschriften Verlag GmbH & Co KG, Helstorfer Str. 7, D-30625 Hannover >E-Mail: [EMAIL PROTECTED] >Phone: +49 511 5352 587; FAX: +49 511 5352 538 > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
