New server, MySQL seems to have some problems with common commands

[schwim]

Hi there guys,

First, allow me to apologize for my ignorance.  Most of what I'm writing is regurgitated from those helping me with my problem, and if something sounds goofy, I just messed up in the transfer of information.

My System:
PHP 4.4.2
MySQL 4.1.21
Apache 1.3.36

My Problem:

I'm moving about 30 sites from one server to another.  During the move, I notice that none of the users can log in anymore to any of the PHP-Nuke sites, e107 sites and a couple other scripts.  We re-upload the sites, re-import the db's, try a lot of stuff, but these guys still can't log in.  So I started working with the support guys at one of the script developer's site, and this is the problem, as he's diagnosed it:

[quote]
When you do a $row = $db->sql_fetchrow($result) you are supposed to return an array into $row that can be accessed either thru the field name or the array element number. (I think I'm saying that right). So, since you are only looking at one field, user_password, that should be in $row[0]. That works on all the systems that I know of but it doesn't work on yours. All I can think of is that maybe it's a bug with your version of mysql. I changed the code in is_user() to access the field by the field name and now it seems to work. I even temporarily did a select * instead of just the user_password and none of the array element references by position seem to work.
[/quote]

So, the scripts are keeping people from logging in, and it's also messing up a lot of other stuff in the page generation.

Is there a setting I need to change to fix this?  An update to MySQL?  I'm at a loss as to what needs to be done, and would appreciate any help and suggestions you can provide.

thanks,
json

[fenway]

This has nothing to do with MySQL, but rather whatever wrapper class you're using to access the DB.

[schwim]

Hi there fenway, and thanks very much for your reply.

If you don't mind, can I ask a couple of questions?  The scripts in question are php-nuke and e107.  I've successfully deployed the scripts on countless servers without any problem before, until this server.  PostNuke works fine, Zen-Cart, Gallery(1 &2), so it's not all login scripts.

My question:

When you say "wrapper class", does that mean the script itself is causing the problem?  If that's the case, why does the scripts work on so many servers?

By your answer, it seems aside from a rollback to a mysql version that I know the script works with, it seems that there are no other solutions aside from not using the offending scripts?

Please forgive my ignorance in the matter, I'm just confused as to why these very popular scripts won't work on my server.  I was sure that it was something I had done wrong.

thanks,
json

[AndyB]

Horrible thought - I wonder if this is a register_globals problem?  If you don't know the answer to that, save the script below as phpinfo.php and upload it to your new server and your old server. Look for significant differences in what you see at both servers when you run it.

[code]<?php
phpinfo();
?>{/code][/code]

[schwim]

Hi AndyB, I tried it both with reg_globals on & off locally through .htaccess, and verifying with phpinfo.

I compared the two php.ini's, (working and non-working enviroment), and didn't see much between the two that should cause the problem.

[url=http://www.schwim.net/info.php]Working enviroment phpinfo[/url]

[url=http://www.roughingthesuspect.com/hold/info.php]Non-Working enviroment[/url]

You can see on the second machine, reg_globals is on locally.

Looking at that, do you see anything that should cause a problem?

Thanks very much for taking the time to help.

thanks,
json

[fenway]

This is out of my league... I'm a MySQL guy, not a PHP guy.