php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #44135 PDO MySQL does not support CLIENT_FOUND_ROWS
Submitted: 2008-02-16 03:26 UTC Modified: 2011-07-03 03:20 UTC
Votes:15
Avg. Score:4.7 ± 0.6
Reproduced:13 of 14 (92.9%)
Same Version:3 (23.1%)
Same OS:6 (46.2%)
From: chx1975 at gmail dot com Assigned: kalle (profile)
Status: Closed Package: PDO related
PHP Version: 5.2.5 OS: Linux
Private report: No CVE-ID: None
 [2008-02-16 03:26 UTC] chx1975 at gmail dot com
Description:
------------
mysql_real_connect supports client flags http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html most importantly CLIENT_FOUND_ROWS but PDO provides no way to pass it in.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-16 03:29 UTC] larry at garfieldtech dot com
I can duplicate this problem.  The issue appears to be that by 
default, MySQL will return the number of affected rows from a 
previous UPDATE statement, not the number of matched rows.  That 
values will differ if the update statement would set a row to its 
existing value.  With ext/mysql and ext/mysqli, it can be set to 
return matched rows instead.  PDO does not appear to have a way to 
allow that.
 [2008-10-23 01:34 UTC] chx1975 at gmail dot com
An attempt to fix this can be found at http://drupal4hu.com/php-44135.patch . I added a number of flags not just the one I needed.

running 
<?php
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '', array(PDO::MYSQL_ATTR_CLIENT_FLAGS => PDO::MYSQL_CLIENT_FOUND_ROWS));
$p->exec('TRUNCATE a');
$p->exec('INSERT INTO a VALUES (1)');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
$p = new PDO('mysql:host=localhost;dbname=test', 'root', '');
echo $p->exec('UPDATE a SET a = 1 WHERE a = 1');
?>
shows a 1 (one row found) and then a 0 (0 updated) so the patch seems to work.
 [2008-10-23 13:25 UTC] johannes@php.net
Thanks for the patch, a few comments/questions:

- Why are you renaming the connect_opts variable? Any particular reason?

- You shouldn't use the numeric values, as they might change, but the values provided by the client library, this also ensures that only flags supported by the library are being used.

- I think the SSL flag won't work without specific SSL certs & stuff, but I have to check that myself
 [2008-10-23 19:55 UTC] chx1975 at gmail dot com
I renamed it to what MySQL calls it. Please just drop the defines then, I copied them from mysql_com.h -- sorry, I am a n00b in doing this. Please also drop any client flags you do not feel useful.
 [2008-10-27 18:36 UTC] johannes@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

New attributes PDO::MYSQL_ATTR_FOUND_ROWS and  PDO::MYSQL_ATTR_IGNORE_SPACE added which can be used while connecting:


$p = new PDO($dsn, $u, $p,
   array(PDO::MYSQL_ATTR_FOUND_ROWS => true, 
         PDO::MYSQL_ATTR_IGNORE_SPACE=> true));
 [2009-02-21 23:48 UTC] kamazee at gmail dot com
This issue is still actual for stable releases _after_ the PHP 5.2.5 (tested 5.2.6 for Linux and 5.2.8 for Windows).
Hope, changes will appear in stable branch soon.
 [2009-08-05 18:54 UTC] lordbyron at sogetthis dot com
Bug still occurs in php 5.2.9, on 64 bit linux. Appears that constant PDO::MYSQL_ATTR_FOUND_ROWS was not added to this version or removed as PDO driver does not recognize it.
 [2009-09-22 01:17 UTC] sadrak at sogetthis dot com
Verified this constant still does not exist in php 5.2.10.
 [2009-10-02 19:48 UTC] lordbyron at sogetthis dot com
Still doesn't exist in 5.2.11, nor does something which would accomplish the same goal.
 [2009-10-02 19:59 UTC] uw@php.net
It is in 5.3+ and not in 5.2 because its a new feature.
 [2009-10-02 21:12 UTC] chx1975 at gmail dot com
So dropping a feature found in both older SQL drivers is not considered a bug?
 [2010-12-16 07:40 UTC] kalle@php.net
-Type: Bug +Type: Documentation Problem
 [2011-07-03 03:20 UTC] frozenfire@php.net
-Status: To be documented +Status: Closed -Assigned To: johannes +Assigned To: kalle
 [2011-07-03 03:20 UTC] frozenfire@php.net
It appears that this the relevant documentation was performed by kalle in October 
of 2010, in this revision: http://svn.php.net/viewvc?
view=revision&revision=304538

I'm marking this bug closed. Any concerns?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 07:01:29 2024 UTC