Just reading the header you put in the question shows something interesting. In fact, the question shows three things:
MySQL dump 10.13 Distrib 5.1.34, for apple-darwin9.5.0 (i386) indicates you used mysqldump from apple-darwin9.5.0 (i386) binariesServer version 5.0.51a-24+lenny2 shows the version of mysql you used mysqldump to dump from.- You wanted to load the mysqldump file into
Ver 14.14 Distrib 5.1.57, for apple-darwin10.3.0 (i386) using readline 5.1
What a jumble of versions to do this with.
If you want to see if mysqldump has an issue with the line that has DATEDIFF, try dumping just the schema.
mysqldump --no-data --all-databases ... > MySQLSchema.sql
This will display ony the schema. No INSERTs will be in the output. You can then hunt down that lines. You may also want to dump the data onyl without the schema,
mysqldump --no-create-info --all-databases ... > MySQLData.sql
Splitting the dumps allows you to load the schema into an editor and see if there are any problems. If you do not see any problems, load the MySQLSchema.sql into the target server. If the error is reproduced, you can fix the schema file and reload. Once the schema is loaded, you can separate load MySQLData.sql
BTW you should use mysqldump binary whose version is 5.0.51a-24+lenny2. Use dumps from version as mysqld is usually better to port and may minimize problems like this.
Give it a Try !!!
I looked over the list of InnoDB options
You have one option that does not appear in the list of Startup Options : innodb
sysdate_is_now = 1
innodb = FORCE <---- No such option called innodb
innodb_strict_mode = 1
I think you meant innodb_force_recovery instead. Before you use it, you need to know the values allowed it.
Here are the options from the MySQL Documentation on Forced Recovery
1 (SRV_FORCE_IGNORE_CORRUPT)
Let the server run even if it detects a corrupt page. Try to make
SELECT * FROM tbl_name jump over corrupt index records and pages,
which helps in dumping tables.
2 (SRV_FORCE_NO_BACKGROUND)
Prevent the master thread from running. If a crash would occur during
the purge operation, this recovery value prevents it.
3 (SRV_FORCE_NO_TRX_UNDO)
Do not run transaction rollbacks after crash recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
Prevent insert buffer merge operations. If they would cause a crash,
do not do them. Do not calculate table statistics.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Do not look at undo logs when starting the database: InnoDB treats
even incomplete transactions as committed.
6 (SRV_FORCE_NO_LOG_REDO)
Do not do the redo log roll-forward in connection with recovery.
With this value, you might not be able to do queries other than a
basic SELECT * FROM t, with no WHERE, ORDER BY, or other clauses. More
complex queries could encounter corrupted data structures and fail.
If corruption within the table data prevents you from dumping the
entire table contents, a query with an ORDER BY primary_key DESC
clause might be able to dump the portion of the table after the
corrupted part.
The database must not otherwise be used with any nonzero value of
innodb_force_recovery. As a safety
Try replacing those lines in my.ini:
sysdate_is_now = 1
# SRV_FORCE_IGNORE_CORRUPT
innodb_force_recovery = 1
innodb_strict_mode = 1
and run
net stop mysql
net start mysql
Give it a Try !!!
UPDATE 2013-02-22 21:29 EDT
@Michael-sqlbot had just pointed out to me that innodb is a MySQL 5.1-specific plugin option to force an all-or-nothing situation: If InnoDB plugin fails to start, mysqld just dies rather than use the built-in InnoDB.
Your solution would simply be to remove that line
sysdate_is_now = 1
innodb_strict_mode = 1
and then restart mysql with
net stop mysql
net start mysql
UPDATE 2013-02-23 08:36 EDT
You may have to resort to putting all DOS paths in double quotes
datadir = "C:\WebSerer\MySQL\data"
or
datadir = "C:/WebSerer/MySQL/data"
also remove the trailing slash
Please try it now...
Best Answer
Perhaps you can change the owner with
Check to see if there is a
[mysqldump]header in/etc/my.cnf. It may look like this:or perhaps under the
[mysqld]headerTry commenting it out and trying mysqldump again.