Are you migrating from 5.0.x to 3.23.x? Do you have any innodb or dbd tables?
-----Original Message----- From: Bing Du To: '[EMAIL PROTECTED] ' Sent: 6/29/04 3:59 PM Subject: RE: Didn't find any fields in table, why? Yup, that's it. I just checked out the mysql online documents. mysqldump should have an option --compatible=name. I tried --compatible=mysql323 with mysqldump on my version 5.0 server, but got "mysqldump: ERROR: unknown variable 'compatible=mysql323'". 'mysqldump --help' does not show --compatible as a valid option. 'mysqldump -V' shows mysqldump Ver 9.10 Distrib 4.0.18, for pc-linux (i686). I also looked through mysqldump help but did not find any option that could be used to produce a backward compatible dump. Any ideas? Bing > ENGINE syntax is availiable in 4.1.x and later versions. > > -----Original Message----- > From: Bing Du > To: [EMAIL PROTECTED] > Sent: 6/29/04 2:30 PM > Subject: Re: Didn't find any fields in table, why? > > Yes, both user and group ownership of the mydb directory and all its sub > directories/files are mysql. > > I also tried on server A 'mysqldump mydb > /tmp/mydb.dump'. Then copy > /tmp/mydb.dump to server B. On server B, I did 'mysql mydb < > /tmp/mydb.dump'. Then I got > > ERROR 1064 at line 11: You have an error in your SQL syntax near > 'ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='List the names and > locations of fi' at line 12 > > Line 12 the above error refers to exists in the following CREATE TABLE > statement: > > 1. CREATE TABLE mytable ( > 2. attachment_id mediumint(5) NOT NULL auto_increment, > 3. task_id mediumint(10) NOT NULL default '0', > 4. orig_name varchar(100) NOT NULL default '', > 5. file_name varchar(30) NOT NULL default '', > 6. file_desc varchar(100) NOT NULL default '', > 7. file_type varchar(50) NOT NULL default '', > 8. file_size mediumint(20) NOT NULL default '0', > 9. added_by mediumint(3) NOT NULL default '0', > 10. date_added varchar(12) NOT NULL default '', > 11. PRIMARY KEY (attachment_id) > 12. ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='List the names and > locations of files attached to tasks'; > > I did a test, seems after removing 'DEFAULT CHARSET=latin1' from line > 12, > the table could be imported fine. Is there some syntax of version 3.* > that is not supported in version 5.*? Like I said, there are a lot > tables > that need to be transferred, manually editting the dump file is not > acceptable. Any workaround? > > Bing > >> >> >> Bing Du wrote: >> >>>I have two mysql servers as shown below: >>> >>>MySQL server A: version 3.23.58, database: mydb, table: mytable >>>MySQL server B: version 5.0.0-alpha-standard-log >>> >>>I want the server B to have the exact same database and table as those > on >>>the server A. So, on server B, I manually created a database called >>>'mydb'. Then I copied three files mytable.frm, mytable.MYD, > mytable.MYI >>>from server A's /var/lib/mysql/mydb/ directory to server B's >>>/var/lib/mysql/mydb directory. >>> >> Make sure mysql owns mydb and all of its files. >> >>> >>>Now on server B, when running the command 'mysql -h localhost -u root > -p >>>mydb', I got the following messages back: >>> >>>---- >>>Didn't find any fields in table 'mytable' >>>---- >>> >>>By the way, I did restart the mysql server on server B after copying >>> files. >>> >>>Does that mean version 3.* can not read version 5.* tables? How > should I >>>set up the same database and tables on another server just by copying >>>files because I have a lot tables that need to be moved over? >>> >>>Thanks in advance for any help. >>> >>>Bing >>> >>> >>> >> >> >> > > > -- > 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] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]