i have tried out with the following configurations:
server1: php-4.0.6/mysql.3.23.32/apache-1.3.20/debian 2.19
server2: php-4.0.6/mysql.3.23.37/apache-1.3.20/debian 2.19

the result is the same as with php-4.0.4pl1

please check this...

thanks
ati

Dear Ati,

When you enter a bug report, please make the script that reproduces the error as short and simple as possible.

I do not believe that the problem that you are encountering is a bug - you just have too many connections open at once.

Try this script:

<pre>
<?php
error_reporting (0);

function test () {
	static $count = 0;

	if (++$count < 20) {
		echo "Opening $count:";
		var_dump ($db = mysql_connect ('localhost:3306', replace_me, replace_me));
	
		test ();

		--$count;
		echo "Closing $count:";
		var_dump (mysql_close ($db));
	} 
}

test ();
?>
</pre>

Now try it with mysql_pconnect -- does the error go away? It does for me.

In most cases, you will only need a *single* connection to a mysql database -- not multiple.

This may still be a bug - two or more calls to mysql_connect with the same arguments should only result in one connection being opened. Each call will return the same connection ID.

Here is a refinement on this bug:

Multiple duplicate calls to mysql_connect are supposed to return the same link ID. Each call after the first call will only return the link ID of the first (if everything goes as planned, the connection is still good, etc...).

    i.e.
    var_dump (mysql_connect() === mysql_connect());

Given this behavior, how should mysql_close() behave?

I would expect that calling mysql_close ($id) would close the connection that both $id and $id2 refer to.

Behavior is not this - instead it is quite odd...

Multiple calls to mysql_close are required to close multiple duplicate calls to mysql_connect.

    i.e.
    var_dump ($db = mysql_connect ());
    var_dump ($db = mysql_connect ()); 
    var_dump (mysql_close ($db)); 
    // Maybe this closes the default connection?
    var_dump (mysql_close ($db)); 

However, if more than two calls to mysql_connect are made, followed by a corresponding number of calls to mysql_close, the mysql_close calls start to fail.

    i.e.
    $max = 10;
    for ($x=0; $x<$max; ++$x) {
        var_dump ($db = mysql_connect());
    }

    for ($x=0; $x<$max; ++$x) {
        var_dump (mysql_close ($db));
    }

Now, throw change the call to mysql_close($db) to mysql_close() - everything seems to work as expected.

However as soon as you add a call to mysql_query after the call to mysql_close, the link will *never* die - no matter how many times you close it.

Finally, put a call to mysql_close ($db) between the two loops. The next call to mysql_close() will fail with an error, while subsequent calls will succeed - once again, the link will never die.

Things get even stranger when this behavior is encountered within recursive function calls - however, I guess that this is a side effect of the behavior described above.

It looks like there is some complex/odd interactions happening with the code that closes mysql links and the code that sets and uses the default link -- however, this is quite far over my head!

Anyone else have any ideas? :)

hi zak,

thanks for your answer.

in my opinion, php must have some matrix, where you stores the number of connect and close calls with the connection id. this will probably solve the problem.

ps: i use these multiple connections in oop environment, where a global connection id, is not the best idea. or?

ati

missing status

Can you try if the problem still persists with latest RC

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.

No feedback. Closing.

sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists.

ati

I will take a look at this.

doh.

If you want to have always a new link, specify the 
optional parameter new_link, which is implemented since 
version 4.2.0.

See also: 
http://www.php.net/manual/en/function.mysql-connect.php

I need to check out how this behaves in the current CVS 

Zak,

I already tested it. Please change the status after you detected some possible errors, not before.

Georg