ID: 29763
User updated by: sigurd at totallydigital dot co dot nz
Reported By: sigurd at totallydigital dot co dot nz
Status: Bogus
Bug Type: MySQL related
Operating System: Debian Linux
PHP Version: 4.3.8
New Comment:
Thank you. This make sense :)
I presume in that case I will revert to standard connect in this case.
It is possible to check the flags that are in operation on a
connection?
It believe it will be worthwhile throwing a mysql warning in pconnect
where the flags requested do not match the flags a connection has.
(It makes me realise there is a dangerous caveat with opening a
persistant 'found_rows' connection, if another independant script
performs a pconnect, expecting normal "affected_rows" behavious).
Previous Comments:
------------------------------------------------------------------------
[2004-08-30 07:04:30] [EMAIL PROTECTED]
mysql_pconnect tries to reuse an exisiting connection with
the same host/port/username/password from connection pool.
If you don't open every connection with same client flags,
it can happen that you will get an exisiting connection,
where these flags weren't set.
You should use mysql_connect or always call mysql_pconnect
with the client_flags you need. It isn't possible to
change client_flags for an existing connection.
------------------------------------------------------------------------
[2004-08-28 22:54:13] sigurd at totallydigital dot co dot nz
Read the original post. I am not asking for it to return changed rows,
I am asking it to return FOUND rows. You are supposed to be able to do
this by setting a flag upon connection and this does was not
experienced.
One reason for using found rows is where you have a standard function
in an abstraction layer to perform updates, and it wants to ensure that
you updated (or could have updated) a row, and throw an error if the
'where' clause returned no rows to update, as opposed to the data being
identical. This makes for wise error checking.
The point is, I set the CLIENT_FOUND_ROWS flag upon connection, which
is supposed to define a certain behaviour, and this behaviour is not
experienced.
Additionally, the behaviour is inconsistant between a normal and
persistant connection.
------------------------------------------------------------------------
[2004-08-28 20:24:03] [EMAIL PROTECTED]
Why would it tell you it changed something when it doesn't?
If you update a field with same data as it was before -> there is no
_change_ or affected rows.
Try the same with the mysql console.
------------------------------------------------------------------------
[2004-08-19 19:46:45] sigurd at totallydigital dot co dot nz
Description:
------------
PHP 4.3.8-5 installed as 'unstable' package from Debian recently.
Background:
The CLIENT_FOUND_ROWS MySQL connection flag is a vital means for
verifying that an UPDATE has affected a row (without doing an
inefficient 'select' afterwards to doublecheck!)
Under 'normal' connection, however, an UPDATE that "updates" values to
what they are in the database already will not increment the
affected-row-count, hence the purpose of the CLIENT_FOUND_ROWS flag,
which when set, DOES return rows that matched the WHERE clause of the
UPDATE.
Bug:
When connecting to a server with
$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);
The CLIENT_FOUND_ROWS behaviour is not experienced.
Merely changing this to a standard connect, does work. (note the
addition of a fourth parameter!) E.g.;
$connectionid = mysql_pconnect($serveraddress, $username, $password,
false, 2);
Reproduce code:
---------------
$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);
// aasume Field was not 1 to begin with;
mysql_query("UPDATE Field=1 WHERE SomeField=1");
print mysql_affected_rows(); // 1
mysql_query("UPDATE Field=1 WHERE SomeField=1");
print mysql_affected_rows(); // 0
// again for good measure.
mysql_query("UPDATE Field=5 WHERE SomeField=1");
print mysql_affected_rows(); // 1
Expected result:
----------------
Each update shold produce an affected row count of one.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=29763&edit=1
