By ystung on

my original system is centos 4.2 with mysql 4.1
I build the system smoothly with several month.
I need to move the system to an old machine(OS :redhat 9 with mysql 3.x)

after i move to the target system , i got the blow message
warning: Wrong parameter count for min() in /www/htdocs/www.dnclass.tw/drupal/includes/menu.inc on line 1198.

after i search the drupal website：
I clean the cache table...
It got correctly after i clean the table...
but it comes back quickly...still the same message...

i try to change the databases encoding from big5 to latin1
when the encoding is latin1, there is no question , every thing is working ok.
when the encoding is big5, it will have problem.
but i can not change the encoding in the target machine. because other application need big5 encoding.
and in mysql 3 , no database level encoding or table level encoding.

can I disable menu cache ?
i setting it in the admin page (disable Page cache)...but not working, may be it not meaning the same thing.

how to disable menu cache?let drupal not use cache table to store the cache information?
can give me a hint?

thanks a lot.

⋅ Categories: Drupal 4.7.x

Comments

chiggsy’s picture

chiggsy commented

Spent a day fixing my db with perl, find ,grep and much swearing with similar issue. If you went from mysql4.1 to mysql (lower) using the silly --compat-40 or similar switches, mysqldump silently strips off the auto_increment fields. Not just drupal, but also:

http://www.zen-cart.com/forum/archive/index.php/t-35770.html

When exporting from mysql4.1 and using the --compat=mysql40 or --compaty-mysql3 flags, mysqldump export command will not give you proper auto-increment flags. This is considered proper behavior by MySQL AB and will not be changed.

Check your auto_increment fields, see if they are still there.

ystung’s picture

ystung commented

thanks for your information.
my original output methmod is not very correct.
when i output from mysql 4.1. i am using phpmyadmin
i did not chose the compatible option(so the compitable option is none).
after i get the sql dump file.
i am clean [DEFALUT CHARSET = UTF-8] by string replace method.
i compare the auto increment number.
it's different when i chose output compitable with mysql323 compare to mysql41

my original method will skip the auto increment problem luckily.
thanks again

chiggsy’s picture

chiggsy commented

yes.. seems that you actually get punished for reading the manual .. that's how i found out about that --compat40 switch. Ahh well , now we know eh?

ymcp’s picture

ymcp commented

I can confirm this "feature/bug":

I'm trying to create a working (test) copy of a Drupal system. The main problem seems to be that the "live" server has mysql v4.1 while the test server has mysql v3.23

For the initial dump you need to use the "compatible=mysql323" flag:

mysqldump --compatible=mysql323 -h${HOST} -u${USER} -p${PASS} ${DBSE} > ${FILE}

After restoring the database and all files on to the test server, everything seemed OK, but within a short time there started to ba a lot of "duplicate key" type errors.

As chiggsy found, this is caused by the "auto_increment" settings being lost when using the "compatible=mysql323" flag.

A (fairly) easy fix seems to be to run the mysqldump command without the "compatible" flag, then cut and paste all the "CREATE TABLE..." statements which have an auto_increment field into another file. Then edit it to change the "CREATE" to "ALTER" (plus a few tiny other changes), so that you end up with a file like this:

ALTER TABLE `access` MODIFY `aid` tinyint(10) NOT NULL auto_increment;
ALTER TABLE `accesslog` MODIFY `aid` int(10) NOT NULL auto_increment;
:
ALTER TABLE `watchdog` MODIFY `wid` int(5) NOT NULL auto_increment;

Then run this script on the mysql v3.23 database. The number of tables affected will depend on which modules you have installed.

Seems to be working so far.

benofsky’s picture

benofsky commented

From what I recall Drupal only supports 4+? Correct me if I'm wrong.
Ben
Benofsky Park.com

ystung’s picture

ystung commented

In INSTALL.mysql.txt says

Depending on the version of MySQL you are using, you must use the
file 'database.4.0.mysql' (for MySQL 4.0 or lower) or
'database.4.1.mysql' (for MySQL 4.1 or higher). Both files are
located in Drupal's database directory.
So I think it support.

interversal’s picture

interversal commented

I found a good work around for this, so I'm posting it around a bit cause it took me ages to find a solution. Basically, I just exported as normal, and did a few well placed 'search and replace'es on the SQL.
From my write up on the issue:
"...
After stuffing around at the command line using options like
mysqldump -uadmin -p`cat /etc/psa/.psa.shadow` -p –skip-opt –create-options –compatible=mysql40 –add-drop-table –default-character-set=latin1 mydb > db.sql

It turns out that a bug in mysql4.1 screws up the creation of auto_increment when exporting with compatible=mysql40

Basically this means that if I export from mysql4.1 to mysql4.0, I have to manually add the AUTO_INCREMENT field type to each of the primary keys in the table. And since I’ve had alot of databases to move, each with up to 100 tables, I didn’t really fancy the idea.

So, after stuffing around I found a work around.

Export as normal from phpmyAdmin,

Do a find and replace on the SQL
Find: DEFAULT CHARSET=latin1
And Replace With:

That is just delete all occurances of: DEFAULT CHARSET=latin1

Then find: timestamp NOT NULL default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
And replace with: timestamp NOT NULL

This seems to do the trick

Worked for a Joomla on 4.1 to 4.0 database conversion
Worked for Zen Cart 1.2.6 to mysql 4.1 to 4.0
Worked for b2Evolution mysql 4.1 to 4.0 database conversion
Worked for Mambo 5 mysql 4.1 to 4.0 database conversion
..."

Or here
http://www.interversal.co.uk/2008/03/18/migrating-from-mysql-41-to-mysql...

:)

Blogging away with PHP and MySQL, but so many fixes to do:

http://interversal.co.uk/