Doc #55059 [Opn->Wfx]: Working of mysql_affected_rows() after SELECT

Edit report at https://bugs.php.net/bug.php?id=55059&edit=1 ID: 55059 Updated by: frozenfire@php.net Reported by: torbasow at mail dot ru Summary: Working of mysql_affected_rows() after SELECT -Status: Open +Status: Wont fix Type: Documentation Problem Package: Documentation problem PHP Version: Irrelevant Block user comment: N Private report: N New Comment: 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 comment. Previous Comments: ------------------------------------------------------------------------ [2011-06-29 00:11:15] torbasow at mail dot ru Description: ------------ --- From manual page: http://www.php.net/function.mysql-affected-rows%23Description --- 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()" (http://dev.mysql.com/doc/refman/5.0/es/mysql-affected-rows.html). This feature should be noted in manual. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=55059&edit=1