|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #55059 Working of mysql_affected_rows() after SELECT
Submitted: 2011-06-29 00:11 UTC Modified: 2011-07-01 18:57 UTC
From: torbasow at mail dot ru Assigned:
Status: Wont fix Package: Documentation problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: torbasow at mail dot ru
New email:
PHP Version: OS:


 [2011-06-29 00:11 UTC] torbasow at mail dot ru
From manual page:
There are nothing about calling mysql_affected_rows() after SELECT. It is logical that it would return 0 because the number of affected rows is zero or the number of affected rows by previous query.

However in practice it returns the number of rows returned by a SELECT! For it is said in MySQL manual that "For SELECT statements, mysql_affected_rows() works like mysql_num_rows()" (

This feature should be noted in manual.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-01 18:57 UTC]
-Status: Open +Status: Wont fix
 [2011-07-01 18:57 UTC]
The behaviour of the mysql_affected_rows() function after calling a SELECT is 
unstable, and varies by MySQL server versions, and I think even with PHP 
versions. I don't think we can reasonably document this behaviour in a way that 
would be future-safe or even understandable to most people.

My suggestion would be to not use this function in this way, as the code will be 
highly non-portable.

As such, I'm changing this bug to wont-fix. If you dispute that, please leave a 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 12 21:01:30 2024 UTC