php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #29763 mysql_pconnect silently ignores the CLIENT_FOUND_ROWS flag
Submitted: 2004-08-19 19:46 UTC Modified: 2004-08-30 07:36 UTC
From: sigurd at totallydigital dot co dot nz Assigned:
Status: Not a bug Package: MySQL related
PHP Version: 4.3.8 OS: Debian Linux
Private report: No CVE-ID: None
View Developer Edit
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: sigurd at totallydigital dot co dot nz
New email:
PHP Version: OS:

 

 [2004-08-19 19:46 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-28 20:24 UTC] sniper@php.net 
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-28 22:54 UTC] 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-30 07:04 UTC] georg@php.net 
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-30 07:36 UTC] sigurd at totallydigital dot co dot nz 
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).
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Apr 07 21:01:29 2025 UTC