Bug #78932 [Csd]: Cannot fetch mysqli_prepare error if $statement variable reused

Edit report at https://bugs.php.net/bug.php?id=78932&edit=1 ID: 78932 User updated by: craig at craigfrancis dot co dot uk Reported by: craig at craigfrancis dot co dot uk Summary: Cannot fetch mysqli_prepare error if $statement variable reused Status: Closed Type: Bug Package: MySQLi related PHP Version: 7.3.12 Assigned To: requinix Block user comment: N Private report: N New Comment: Thanks @requinix, that does make it clearer. I think the issue I've been having is the abstraction, vs what's happening in the background. Using a single $link variable as the way to get the "last" error is not ideal (considering that it's not clear as to what action you're checking). Maybe future mysqli implementations/abstractions will make this and other things easier - my main issue being that bind_param() is not easy for new programmers, but that's a different topic for a different day :-) Previous Comments: ------------------------------------------------------------------------ [2020-12-08 20:14:03] requinix@php.net D'oh. > When the prepared statement gets cleaned up during (2b) (2a) ------------------------------------------------------------------------ [2020-12-08 20:13:04] requinix@php.net @craig: Assuming I followed correctly, here's an alternative explanation that might help: 1 $statement = mysqli_prepare(...); 2 $statement = false; 3 $statement = mysqli_prepare(...); Or in a little more detail, 1a temp var <- mysqli_prepare(...); 1b new var $statement <- temp var 2a clean up the contents of $statement 2b $statement <- false 3a temp var <- mysqli_prepare(...) 3b clean up the contents of $statement 3c $statement <- temp var When the prepared statement gets cleaned up during (2b), that process includes closing out the statement with the server, and the result of that gets remembered for mysqli_error/errno. You could then check this if you wanted. In step (3a), the new statement has an error and then that gets remembered. The important part here is that if you comment out step (2), you still reuse $statement so the same cleanup process still happens with the old statement, but now it happens *after* the new statement was prepared. That means the unsuccessful act of creating the statement in (3a) is overwritten by the successful act of cleaning up the old statement in (3b). With automatic errors, the error during (3a) would be immediately reported. ------------------------------------------------------------------------ [2020-12-08 18:51:13] craig at craigfrancis dot co dot uk Thanks for the update. I think I follow, even though it's still a bit weird/unexpected. ------------------------------------------------------------------------ [2020-12-08 01:02:50] dharman@php.net Although unexpected, this is the correct behaviour. As nikic explained the destructor of mysqli_stmt is called once a new value is assigned to the same variable. The destructor performs a close operation on the MySQL server. Each time a command is sent, the error message is reset. You would need to check the error message before the mysqli_stmt is closed. Your code example would be equivalent to the following: if (false === ($statement1 = mysqli_prepare($link, 'SELECT 1'))) { exit(mysqli_errno($link) . ': ' . mysqli_error($link)); } if (false === ($statement2 = mysqli_prepare($link, 'SELECT 1 FROM this_table_does_not_exist'))) { exit(mysqli_errno($link) . ': ' . mysqli_error($link)); } if (false === mysqli_stmt_close($statement1)) { exit(mysqli_errno($link) . ': ' . mysqli_error($link)); } if (false === mysqli_stmt_close($statement2)) { exit(mysqli_errno($link) . ': ' . mysqli_error($link)); } However, the recommended practice would be to enable automatic error reporting and stop worrying about manual error checking. With automatic error reporting an exception is triggered as soon as the error happens. To enable automatic error reporting just add the following line before making a connection. mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); ------------------------------------------------------------------------ [2019-12-09 08:36:55] nikic@php.net The problem here is that the original $statement gets destroyed when the next assignment to the variable happens (that is, after the second prepare has finished). When the old $statement is destroyed a close_on_server operation on the statement is issued. This is going to reset the error state, because it performs a number of operations that may in themselves fail (like exhausting the result and closing the statement), and the error result from those operations will be used. As they don't fail, the error ends up being zero. I don't really know what we should be doing about this. I guess one possibility is to back up the error information before we do an *implicit* close, as opposed to an explicit close with mysqli_stmt_close() (in which case we *do* want to report errors from that operation). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78932 -- Edit this bug report at https://bugs.php.net/bug.php?id=78932&edit=1