Object of class mysqli_result could not be converted to string in XYZ

PHP
1

So. This is pretty weird.

file.php has routine.php included. file.php calls for functions in routine.php, to no avail. So it looks like this:

This line fails:

var_dump(writeQuery("***"));

*** replace it with query that works! I checked it in SQL. And yes there’s MySQL connection this whole time, otherwise previous queries (also featuring writeQuery()) would fail.

The writeQuery() is a flat function says:

	function writeQuery($query) {
		global $dbconn;
                return $dbconn;
	}

I removed commented lines (this is why this function doesn’t make sense to you). But before I started commenting stuff out I had:


	function writeQuery($query) {
		global $dbconn;
		$dbresult = $dbconn->query($query);
		return $dbresult->affected_rows > 0 ? true : false;
	}

Both of these queries fail with same message.

Any ideas?

2

You were editing the wrong file. Sometimes it happen to all of us.

Send yourself a message, like die('It's me!'); to make sure you are editing the right file.
Also pay attention to that XYZ thing. usually it can give you a hint where to find the problem row.

3

I was certain I was editing the correct file.
Now that you hinted at it and I verified.
I’m certain I’m editing right files. Moving any part of dependancies or the script itself change the outcome (missing (removed) functions “fatal error missing functions”, die() (in middle of executions) etc.) react way that they should. But this error is still there. I am changing the correct files.

4

Then pay attention to that XYZ thing. usually it can give you a hint where to find the problem row.

5

That’s the file, and I gave the row:

var_dump(writeQuery("***"));

brings the error, it points on this file, on this row.
Catchable fatal error: Object of class mysqli_result could not be converted to string in ---.php on line 24. File and row point to it.

---.php:24 is var_dump(writeQuery("***"));
Where *** is successful (upon manual input) query.

6

And what is behind ***? A variable I suppose? And this variable is…

Or there is an ugly SQL query with PHP variables all over the place. and one of these variables is mysqli result object.

1 Like
7

Let me suggest you to use this function

function myQuery($query, $params = NULL, $types = NULL)
{
    global $mysqli;
    $stmt = $mysqli->prepare($query);
    if ($params)
    {
        $types = $types ?: str_repeat('s', count($params));
        $stmt->bind_param($types, ...$params);
    }
    $stmt->execute();
    return $stmt->field_count ? $stmt->get_result() : $stmt;
}

with it you can start using prepared statements instead of stuffing php veriables right into SQL query. For example:

$user = myQuery('SELECT * FROM users WHERE id=?;', [$id])->fetch_assoc();

or, better yet, start using PDO.

1 Like
8

Your solution has brought to me to think about something.
Which I used to solve a problem. Which made 3 new problems,
that I also solved, now there’s a new problem, which doesn’t make
sense, I know why, but I don’t know how.

As of prepared statements. My stupid host doesn’t support prepared statements, and finding good free hosting is pretty tough (for presentation). Don’t suggest anything, and don’t ask why they don’t support prepared statements. I don’t know. I don’t care, I just want to be done with this stupid job.

As for PDO. This has been suggested a lot. And I wanted to start “learning” it and apply to my future projects, but for this one I have to stick with old trashes. Using PDO would take longer time than struggle with whatever I’m doing.

Essentially you fixed the problem, so thank you, I’ll have to make new thread for new problem.

9

Are you certain?

Prepared statements have been available since PHP 5.0 was released back in 2004.

The only 5x version that is still supported is 5.6

If your host doesn’t support a version that was released 12 years ago, even if the host is 100% entirely free it isn’t worth the price to stay with them.

10

Both mySQLi and PDO have supported prepare statements since they were first introduced in July 2004.

Only the old mysql_ interface removed in December 2015 didn’t support prepare statements.

It is the database access you are using that determines if prepare statements are supported not the hosting.

11

Ah, I hadn’t thought of that possibility.

@NoFlag don’t confuse MySQL the database with mysql the obsolete interface.

12

@Mittineague @felgall

It’s not that. It’s long time ago, but there was like part of SQL missing. For some reason. They don’t have drivers or something. [quote=“felgall, post:10, topic:237185”]

It is the database access you are using that determines if prepare statements are supported not the hosting.
[/quote]
Yea, but host dictates my database access…

13

they dictate what databases you can access but PHP dictates how you can access them and both of the access methods that PHP support allow for prepare statements to be used.

The host cannot dictate what parts of PHP they do and don’t support - just which versions of PHP they support. Only PHP 4 (now over 10 years dead) did not support prepare statements and those working on PHP itself only support PHP 5.6 and PHP 7 so if your host isn’t providing one or both of those then they are not providing a current version of PHP and you need to find a new host if you want to use PHP. If your host only provides PHP 5.5 or earlier then don’t use their hosting for PHP as those versions of PHP can contain security holes and other bugs that will never be fixed.

1 Like
14

YOU HAVE THE PREPARED STATEMENTS ON YOUR HOST. Period.

I dunno what are your reasons to deny the fact. May be you don’t like the prepared statements yourself or your host is lying to you, but from your question it is obviously evident that you have full support for the prepared statements. Your question title says that your code is using mysqli. And mysqli has full support for the prepared statements.

So please, at least don’t try to sell it here.

15

I DON’T HAVE PREPARED STATEMENTS ON MY HOST. Period.

My reason to deny that “fact”. Is when I crafted prepared statement script on my computer, it worked, then I uploaded and errors started popping out. They looked extremely cryptic and no, those weren’t faulty SQL queries or misconnections.

Anyways, I’m not here to argue. I’m done. You can keep telling me to turn on the lightbulb, and I can keep telling you we’re in Middle Ages. You’re not here to witness.

16

You’re free to go. I asked for help, it’s you who decided to ponder this topic. I clearly said:

17

Ok, it’s clear now. Your reasons are the error messages that were “too cryptic” for you. So you can keep thinking your technology is the middle ages. Just don’t forget to tell that the customer you are trying to sell the code to.

18

Who is your hosting provider may I ask? I would like to research and see if they do support prepared statements or not. It’s quite odd that hosts like yours don’t support prepared statements. Makes it worse since 000webhost is free and supports prepared statements and they’re running on 5.2 as well. If you are using a free hosting provider, I suggest using something other than that current one you have.

Try x10hosting.com

19

So why not post them here - what is cryptic to you will probably be obvious to many of the people here.

1 Like
20

Indeed. Just seeing “could not be converted to string” suggests the probable issue to me.

I imagine it involves the $dbconn object.

Of course without seeing the actual code involved the best I can offer as a fix is

change *** on line *** in the *** file to ***