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
<gleb.paharenko@stripped> 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.
>
>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
>
>
>
>
>--
>MySQL General Mailing List
>For list archives: http://lists.mysql.com/mysql
>To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>
>
