PHP 8.2 - mysqli_report(MYSQLI_REPORT_OFF) doesn't work

[Zeux]

Hi to all,

this is my environment:

• OS: Ubuntu 22.04
• PHP version; 8.2
• PHP Repository: ondrej (deb https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main)
• Webserver: Nginx
• DB: Mariadb 10.10.6

I can connect to Mariadb and execute the query, but if a query returns an error, php stops to continue the code and returns a "Fatal error". My code to connect to Mariadb is:

 

mysqli_report(MYSQLI_REPORT_OFF);
$link = mysqli_connect($db_host, "$db_username", "$db_pwd", "$db_name", $db_port, "$db_socket");

and the connection is OK, no problem!

 

As I want to handle the errors, I use the following code:

$results=mysqli_query($link, $query);
$num_rows=mysqli_num_rows($results)
if(!is_numeric($num_rows) OR $num_rows<0) {
 // Return an error message and exit                            
}

// If there is not error the php scrip continue...
                                         

Now the problem is that the function mysqli_num_rows($results) cause a Fatal error and no other codes is executed.

 

Fatal error: Uncaught TypeError: mysqli_num_rows(): Argument #1 ($result) must be of type mysqli_result, bool given in ....

TypeError: mysqli_num_rows(): Argument #1 ($result) must be of type mysqli_result, bool given in ...

 

I know that from PHP 8.1 MySQLi's default error mode is changed from MYSQLI_REPORT_OFF to MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT and therefore, before to connect to Mariadb, I use the command:

• mysqli_report(MYSQLI_REPORT_OFF)

but it doesn't work. Why?

 

Could someone help me, please?

 

Thank you very much!

[kicken]

23 minutes ago, Zeux said:

but it doesn't work. Why?

The error you are getting has nothing to do with Mysql.  It's a PHP error caused by trying to pass the wrong type of variable to a function.  You'd get a similar error if you did something like:

$variable = 'Hello, World';
echo array_reverse($variable);

Your query has a problem, so the mysqli_query function returns a boolean false value to indicate that the query failed.  You're taking this value and passing it to mysqli_num_rows which is expecting a valid query result as it's parameter, not a boolean false.

By turning off the error reporting, you are now responsible for checking if your queries have failed or not and proceeding accordingly.  So the solution is either to stop turning error reporting off, or add code that checks if mysqli_query failed and returned false.

 

[mac_gyver]

the error you are getting is a follow-on error, because there was no error handling at the query() call that failed, and the code continued to run and tried to use the a result that doesn't exist.

you ALWAYS need error handling for statements that can fail. for database statements that can fail - connection, query, exec, prepare, and execute, the SIMPLEST way of adding error handling, without adding logic at each statement, is to use exceptions for errors and in most cases simply let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) the exception to this rule is when inserting/updating duplicate or out of range user submitted data. in this case, your code should catch the exception, test if the error number is for something that your code is designed to handle, then setup a message telling the user what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it.

by turning off exceptions for the mysqli error handling, you must now handle errors for each of these statements, which means you must write conditional logic testing the result from each statement call and take an appropriate action, such as preventing the following code from being executed if a statement call failed. 

[mac_gyver]

1 hour ago, Zeux said:

As I want to handle the errors, I use the following code:

this code is attempting to test the number of rows in a result set for a successful (no execution error) query. (you should actually just fetch the data and test if there was fetched data, since you want to use the data if it exists, simplifying the code.)

the php errors you are getting mean that the query didn't execute at all, due to things like an sql syntax error, wrong database or no database selected, incorrect table or column names, incorrect use of aggerate functions, ...

having error handling for the database statements that can fail, will mean that this code, testing the number of rows in a result set, will only get executed if the query executed successfully, without errors. this is one of the great points of using exceptions for error handling. your main code will only see and deal with error free execution of statements that can throw exceptions, since execution transfers to the nearest correct type of exception handling upon an error or to php if there is no correct type exception handling in your code.

[Zeux]

Hi,

my code, with php 7.4 - 8.0, works perfectly. It stops to work from php 8.1 because MySQLi's default error mode is changed from MYSQLI_REPORT_OFF to MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT. How can I reproduce the behavior of php 7.4 - 8.0 ?

 

Thank you

[mac_gyver]

you have jumped to an incorrect conclusion about what is occurring.

an sql query that has no programming mistake doesn't produce any php errors when accessing the result from that query, regardless of php version.

you are getting php errors because there's something wrong with the specific sql query in question with the code you are posting. if you do what has already been suggested and add error handling, you can find out what is wrong with the query. if you want anyone here to help, you will need to post the sql query.

i'm going to guess that you are putting a value, in a php variable, directly into the sql query statement, in a numerical context, such as an id, but the value is empty, resulting in an sql syntax error. this is a programming mistake. the correct way to fix this is to validate inputs, only execute a query when 'required' inputs have an expected value, and to use a prepared query so that any sql special characters in a value cannot break the sql query syntax.