Grey_Magus has asked for the wisdom of the Perl Monks concerning the following question:

We have a number of Perl scripts which connect to a MySQL server from a Solaris 5.9 box

We are now upgrading to a new SunOS 5.10 server, but attempting the run the same scripts to connect to the same MySQL server no longer works.

The user I'm using to connect to the database does not have a password. However, when I try to connect using this user from the new Solaris box with the same scripts, I get the following error:

DBI connect('database=production;host=SERVER;port=PORT','USER',...) failed: #28000Access denied for user 'USER'@'SERVERNAME.DOMAIN.com' (using password: YES) at /usr/local/lib/perl5/site_perl/5.8.7/DBD/mysqlPP.pm line 109

I find the '(using password: YES)' message somewhat troubling as I'm passing a blank password. Strangely, if I assign a password to this user, I can connect to it without error (assuming I update the script to connect using the new password, of course.)

I'm using Perl v5.8.7 built for sun4-solaris and DBI 1.54, which are both slighter newer than what is on the older box. In the hopes that this was a flaw in the newer DBI, I downgraded the module to the version we were using, but this gives the same results. I'm using DBD-mysqlPP v0.04 to connect to the database.

I went code diving to see if I could find a flaw in the way the module handles blank passwords, but I didn't see anything obvious.

At this point I remain uncertain if I have a Perl or a MySQL problem. And ideas?

Replies are listed 'Best First'.
Re: DBI Access Denied with blank password
by rodion (Chaplain) on Apr 13, 2007 at 01:12 UTC
    From the MySQL documentation of access-denied
    If you get the following error, it means that you are using an incorrect root password:

    shell> mysqladmin -u root -pxxxx ver
    Access denied for user 'root'@'localhost' (using password: YES)

    If the preceding error occurs even when you have not specified a password, it means that you have an incorrect password listed in some option file. Try the --no-defaults option as described in the previous item.

    Also note that it's somtimes necessary to include a specific entry for "localhost" in the authroiztion tables, even though there is a wild-card entry that you think should cover the "localhost" case. It has to do with precedence and interactcion between tables, I think, but I can't find the spot in the documentation that mentions it, from where I am right now.
      Current testing suggests our problem is a Perl issue, as I've strayed from The Path and created a simple test case in a different language that is able to connect both as a user with and without a password.

      As an added clue, while I can connect to the database using the DBI and a user with a password, the user seems to time out doing select queries. It can do inserts and updates, but sending select statements seem to cause the connection to hang.

        Try a different driver (DBD)