Re: Trouble w/ mysqldump (images attached)

2005-01-12 Thread Hurrican19
Thanks for all your help Gleb!  I Appreciate all your hard work!  


In a message dated 1/12/2005 5:31:19 AM Eastern Standard Time, Gleb Paharenko 
[EMAIL PROTECTED] writes:

Hello.

[mysqldump]
default_character_set = latin1



[EMAIL PROTECTED] wrote:
 amazing.. I failed to see that in the last msg - but that seemed to do the 
 trick - The images appear correctly now..   is there anyway in my.cnf to 
 tell it to always use the command??  Thanks much for the help!
 
 
 In a message dated 1/11/2005 4:48:27 AM Eastern Standard Time, Gleb 
 Paharenko [EMAIL PROTECTED] writes:
 


-- 
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]



Re: Trouble w/ mysqldump (images attached)

2005-01-11 Thread Hurrican19
amazing.. I failed to see that in the last msg - but that seemed to do the 
trick - The images appear correctly now..   is there anyway in my.cnf to tell 
it to always use the command??  Thanks much for the help!


In a message dated 1/11/2005 4:48:27 AM Eastern Standard Time, Gleb Paharenko 
[EMAIL PROTECTED] writes:

Hello.

Have you tried to perform the dump using --default-character-set=latin1
option and then restore data from it?

[EMAIL PROTECTED] wrote:
 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
 


-- 
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]



Re: Trouble w/ mysqldump (images attached)

2005-01-10 Thread Hurrican19
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 ? 

RE: Trouble w/ mysqldump (images attached)

2005-01-07 Thread Hurrican19
I have reinstalled the v3 RPM again to my system, and used one of my original 
backups from that same version.  In 3.23 there is no 'collation' field.. I 
wonder if that is the problem??   I am going to change it to latein1_bin to see 
what happens next.. 

Thanks!  I'll let you know!


In a message dated 1/7/2005 3:44:25 AM Eastern Standard Time, Tom Molesworth 
[EMAIL PROTECTED] writes:

Hi there,

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote on Thursday, January
06, 2005 7:19 PM:
     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

It'd be better to use a BLOB, I think, because this would avoid the
translation issues. Other alternatives worth pursuing:

* Add the BINARY flag to the field - avatardata MEDIUMTEXT BINARY, for
example.
* Use a different collation, preferably one that's not case insensitive (the
'ci' part of the collation)
* Use latin1_bin on the new DB (and you might need to use
_latin1_bindata instead of just data when doing inserts)
http://dev.mysql.com/doc/mysql/en/Charset-literal.html
* Force the collation type, using the COLLATION keyword, as in
http://dev.mysql.com/doc/mysql/en/Charset-collate.html

 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..

If you want to send me (directly, rather than via the list) one of the
records, as taken from both the bad and good versions, I could take a look
for you. The binary files differ, so I'm not too sure what data is being
used when you did the paste-and-compare.

 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?

Shouldn't need to recompile, as long as you have the right charactersets
available (which should be the default, I think).

cheers,

Tom



-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Trouble w/ mysqldump (images attached)

2005-01-07 Thread Hurrican19
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]



Re: Trouble w/ mysqldump

2005-01-06 Thread Hurrican19
I am confused over the much smaller DataBase, but also of the corrupted avatars 
and file attachments (I've attached examples).. I did some research using 
mysqladmin, and the 'attachment' and the 'customavatar' tables are exactly the 
same size in both databases, but the entire DB is about 10MB smaller on the 4.1 
dump (according to mysqladmin) But the difference in my acutal dump files is 
70MB..

I was told by vBulletin that they think it has somthing to do with the way 
mysql 4.1.X handles tables with languages and character encoding?

Thanks!

In a message dated 1/5/2005 12:16:19 PM Eastern Standard Time, Gleb Paharenko 
[EMAIL PROTECTED] writes:

Hello.

 Right, three is a true dump file, and I can restore the database, everything 
'seems' to be there,

So, as I understand, the only thing that were confusing you, was the small
dump file? If you see binary files after restoring from the dump file -
they are in the dump file. I think that clues are in the bulk inserts which
are tighter than ordinary.


you [EMAIL PROTECTED] wrote:
 Right, three is a true dump file, and I can restore the database, everything 
 'seems' to be there, I can browse the table all day long, and I can see the 
 binary files in the database, but the length of the tables are different.
 
 mysql@lists.mysql.com
 In a message dated 1/5/2005 3:50:39 AM Eastern Standard Time, Gleb Paharenko 
 [EMAIL PROTECTED] writes:
 
Hello.

 The actual tables are there 

I assume that 'there' is a dump file. One more question, can you
select the Avatars data using SQL queries? For example:
  SELECT 'Avatar_field' from 'avatar_table' limit 1;
Does your application work after upgrade?


[EMAIL PROTECTED] wrote:
 Thanks for the reply.
 My original install was w/ an RPM from the Redhat Network, I uninstalled 
 all RPM's associated w/ MySQL, Apache, and PHP and downloaded the latest 
 of everything and compiled it. After I did an updatedb on my box, I 
 searched for mysqldump and mysql to confirm it was gone -- nothing was 
 found.   
 
 ./mysqldump Ver 10.9 Distrib 4.1.8a, for redhat-linux-gnu (i686)
 
 The actual tables are there, but the images (or any attachments) are 
 really messed up.  Looks like something from the 60's, lol.
 
 In a message dated 1/4/2005 9:36:01 AM Eastern Standard Time, Gleb 
 Paharenko [EMAIL PROTECTED] writes:
 
Hello.

In what way have you upgraded? How do you dump the data? Is everything 
fine,
execept the database dump? As of MySQL 4.1, --opt command line option is 
on by 
default, so it can produce a smaller output. The definions of tables
which stores Avatars are also absent in dumps? May be you use mysqldump
from old 3.23 version?


[EMAIL PROTECTED] wrote:
 Hi All,
 I run a website, and am having a problem w/ corrupt databases..
 
 I was runnig MySQL v3.23 previously, and my db dumps worked fine .. 
 However, I have since upgraded to v4.1.8a-log and I am having problems 
 getting completed (or non corrupt) backups.. The problem is pretty big..
 
 My Original Backup of the DB using 3.23 was 208MB --- When I upgraded to 
 4.18 the backup is only 138MB ... My users Avatar's, all attachments, 
 etc are totally whacked out. Does anyone have any insight on what is 
 causing this, and how to fix it? Any help is appreciated.. I need a new 
 good backup desperately 
 






-- 
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]



Re: Trouble w/ mysqldump (images attached)

2005-01-06 Thread Hurrican19
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
attachment: brokenavatar.jpegattachment: goodavatar.jpeg-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

RE: Trouble w/ mysqldump (images attached)

2005-01-06 Thread Hurrican19
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..

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]



-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Trouble w/ mysqldump

2005-01-05 Thread Hurrican19
Right, three is a true dump file, and I can restore the database, everything 
'seems' to be there, I can browse the table all day long, and I can see the 
binary files in the database, but the length of the tables are different.

mysql@lists.mysql.com
In a message dated 1/5/2005 3:50:39 AM Eastern Standard Time, Gleb Paharenko 
[EMAIL PROTECTED] writes:

Hello.

 The actual tables are there 

I assume that 'there' is a dump file. One more question, can you
select the Avatars data using SQL queries? For example:
  SELECT 'Avatar_field' from 'avatar_table' limit 1;
Does your application work after upgrade?


[EMAIL PROTECTED] wrote:
 Thanks for the reply.
 My original install was w/ an RPM from the Redhat Network, I uninstalled all 
 RPM's associated w/ MySQL, Apache, and PHP and downloaded the latest of 
 everything and compiled it. After I did an updatedb on my box, I searched 
 for mysqldump and mysql to confirm it was gone -- nothing was found.   
 
 ./mysqldump Ver 10.9 Distrib 4.1.8a, for redhat-linux-gnu (i686)
 
 The actual tables are there, but the images (or any attachments) are really 
 messed up.  Looks like something from the 60's, lol.
 
 In a message dated 1/4/2005 9:36:01 AM Eastern Standard Time, Gleb Paharenko 
 [EMAIL PROTECTED] writes:
 
Hello.

In what way have you upgraded? How do you dump the data? Is everything fine,
execept the database dump? As of MySQL 4.1, --opt command line option is on 
by 
default, so it can produce a smaller output. The definions of tables
which stores Avatars are also absent in dumps? May be you use mysqldump
from old 3.23 version?


[EMAIL PROTECTED] wrote:
 Hi All,
 I run a website, and am having a problem w/ corrupt databases..
 
 I was runnig MySQL v3.23 previously, and my db dumps worked fine .. 
 However, I have since upgraded to v4.1.8a-log and I am having problems 
 getting completed (or non corrupt) backups.. The problem is pretty big..
 
 My Original Backup of the DB using 3.23 was 208MB --- When I upgraded to 
 4.18 the backup is only 138MB ... My users Avatar's, all attachments, etc 
 are totally whacked out. Does anyone have any insight on what is causing 
 this, and how to fix it? Any help is appreciated.. I need a new good 
 backup desperately 
 




-- 
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]



Trouble w/ mysqldump

2005-01-04 Thread Hurrican19
Hi All,
I run a website, and am having a problem w/ corrupt databases..

I was runnig MySQL v3.23 previously, and my db dumps worked fine .. However, I 
have since upgraded to v4.1.8a-log and I am having problems getting completed 
(or non corrupt) backups.. The problem is pretty big..

My Original Backup of the DB using 3.23 was 208MB --- When I upgraded to 4.18 
the backup is only 138MB ... My users Avatar's, all attachments, etc are 
totally whacked out. Does anyone have any insight on what is causing this, and 
how to fix it? Any help is appreciated.. I need a new good backup desperately 

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Trouble w/ mysqldump

2005-01-04 Thread Hurrican19
Thanks for the reply.
My original install was w/ an RPM from the Redhat Network, I uninstalled all 
RPM's associated w/ MySQL, Apache, and PHP and downloaded the latest of 
everything and compiled it. After I did an updatedb on my box, I searched for 
mysqldump and mysql to confirm it was gone -- nothing was found.   

./mysqldump Ver 10.9 Distrib 4.1.8a, for redhat-linux-gnu (i686)

The actual tables are there, but the images (or any attachments) are really 
messed up.  Looks like something from the 60's, lol.

In a message dated 1/4/2005 9:36:01 AM Eastern Standard Time, Gleb Paharenko 
[EMAIL PROTECTED] writes:

Hello.

In what way have you upgraded? How do you dump the data? Is everything fine,
execept the database dump? As of MySQL 4.1, --opt command line option is on by 
default, so it can produce a smaller output. The definions of tables
which stores Avatars are also absent in dumps? May be you use mysqldump
from old 3.23 version?


[EMAIL PROTECTED] wrote:
 Hi All,
 I run a website, and am having a problem w/ corrupt databases..
 
 I was runnig MySQL v3.23 previously, and my db dumps worked fine .. However, 
 I have since upgraded to v4.1.8a-log and I am having problems getting 
 completed (or non corrupt) backups.. The problem is pretty big..
 
 My Original Backup of the DB using 3.23 was 208MB --- When I upgraded to 
 4.18 the backup is only 138MB ... My users Avatar's, all attachments, etc 
 are totally whacked out. Does anyone have any insight on what is causing 
 this, and how to fix it? Any help is appreciated.. I need a new good backup 
 desperately 
 


-- 
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]