php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #34906 mysql: no way to get errno for a failed secondary connection attempt
Submitted: 2005-10-18 13:19 UTC Modified: 2012-05-04 16:01 UTC
Votes:7
Avg. Score:4.7 ± 0.7
Reproduced:6 of 6 (100.0%)
Same Version:0 (0.0%)
Same OS:4 (66.7%)
From: feldgendler at mail dot ru Assigned: mysql (profile)
Status: Wont fix Package: MySQL related
PHP Version: 5CVS-2005-10-19 (cvs) OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: feldgendler at mail dot ru
New email:
PHP Version: OS:

 

 [2005-10-18 13:19 UTC] feldgendler at mail dot ru
Description:
------------
This is actually a bug in the well-defined and documented API, so there is no reproduce code here.

After successfully establishing a connection, when an attempt to create another connection fails, there is no way to find out the errno. This is because mysql_errno() always uses an established link, either the one passed as the argument or the default one. There is just no way to find out why the second connection failed.

// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);

// at this point, $first_connection is the default link

// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);

// $second_connection is false,
// $first_connection is still the default link

echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection

Before stamping "Bogus" on this bug, please note the following:

1. I have read the manual about mysql_errno() and mysql_connect(). Every word of it. Even more, I think that PHP currently behaves as documented. But it's just wrong because there is no way to find out why a connection has failed.

2. I have read other bug reports about mysql_errno(). They are actually about other issues, or they don't state this problem clearly enough, so I'm filing this bug report to make it clear what the problem is.

3. I have read the source code of the mysql extension. From the source, I've found out that the error code and message from a failed connection attempt is really stored in mysql_globals (connect_errno and connect_error), but mysql_errno() PHP function only returns MySG(connect_errno) when the function is invoked without arguments AND there is no default link. If there is a default link, and an attempt to establish a second one has failed, there isn't a way to have MySG(connect_errno) returned to the PHP program.

It is not obvious how to fix this bug, because it isn't a deviation from the documented behavior, but rather an incompleteness of the API. Two of the possible approaches are proposed here:
http://www.mail-archive.com/internals@lists.php.net/msg02524.html


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-18 13:43 UTC] tony2001@php.net
Assigned to the maintainer.
Georg, please check the patch: 
http://tony2001.phpclub.net/dev/tmp/bug34906.diff
 [2005-10-18 13:51 UTC] feldgendler at mail dot ru
About the patch: I think it's not enough. Once a connection attempt has failed, conect_errno will be nonzero, and mysql_errno() without arguments always will return this value. This will be too much deviation from the current behavior -- in fact, many always call mysql_errno() without arguments. Here is a typical script which will be broken:

if (!mysql_connect('dbhost', 'user', 'pass')) {
    mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query("...")) {
    echo mysql_errno(); // This will print connect_errno!
}

I think that connect_errno should be reset to zero somewhere, but I don't know where it would be appropriate. mysql_errno() shouldn't reset connect_errno because mysql_error() and mysql_errno() are expected to be idempotent.
 [2010-12-20 14:14 UTC] jani@php.net
-Package: Feature/Change Request +Package: MySQL related
 [2011-02-16 11:43 UTC] tony2001@php.net
-Assigned To: georg +Assigned To: johannes
 [2011-02-16 11:43 UTC] tony2001@php.net
Reassigned to Johannes.
The patch is still available here: http://dev.daylessday.org/diff/bug34906.diff
 [2011-02-16 12:07 UTC] johannes@php.net
-Assigned To: johannes +Assigned To: mysql
 [2011-02-16 12:07 UTC] johannes@php.net
The "easy" solution is to use mysqli without this default connection magic.

Making this work doesn't look trivial as these two cases have to work:

mysql_connect('localhost', 'valid', 'password');
mysql_connect('localhost', 'invalid', 'something');
mysql_query('invalid query');
echo mysql_error(); // should report the query error

as well as

mysql_connect('localhost', 'valid', 'password');
mysql_query('invalid query');
mysql_connect('localhost', 'invalid', 'something');
echo mysql_error(); // Should report the connect error

Assigning to mysql team
 [2012-05-04 16:01 UTC] uw@php.net
-Status: Assigned +Status: Wont fix
 [2012-05-04 16:01 UTC] uw@php.net
It may be a valid feature request but meanwhile ext/mysql is in the process of being softly deprecated. So, no feature additions for ext/mysql any more. Security fixes, sure, feature additions, sorry, migrate to ext/mysqli.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 03:01:28 2024 UTC