[DONE] Object of class queryFactoryResult could not be converted to int

[Zola]

I was working on writing an admin module and had set up my own error handler and kept on seeing

Notice: Object of class queryFactoryResult could not be converted to int unknown 0

This was showing on every single admin page, and when I turned on the E_ALL in the user pages, it was at the bottom of each of those pages too, although it claimed it was happening in application_bottom.php on line 13. When I commented out the session_write_close() line, it continued to appear but with the frustratingly familiar unknown 0;

I will not bore you to tears with the details of getting it figured out, I'll just share the cause and the solution.

Cause:

When you run anything through the Execute() function in query_factory.php, it creates an object. That object contains the resource id among other things. The pertinent line, which occurs more than once, is:

$zp_db_resource = @mysql_query($zf_sql, $this->link);


After an error check, $obj->resource is set to $zp_db_resource.

The problem occurs when the query doesn't return a resource id.

This happens whenever a non-recordset query is made, like update or delete--instead of returning a resource id, the function returns "true" to show that the query executed successfully.

Since $obj->resource has already been set with a resource during previous queries, what happens is that the code overwrites whatever is currently in there with 1 (for "true"), and produces the notice since the variable type is being changed.


Solution:

Rather than write a function especially for non-recordset queries, the answer is to add a few lines of code to the query factory.

After every appearance of the following lines:

$zp_db_resource = @mysql_query($zf_sql, $this->link);
if (!$zp_db_resource) $this->set_error(@mysql_errno(),@mysql_error());

add this statemnt:

if(!is_resource($zp_db_resource)){
      	 $obj = null;
      	 return;
}

What it does is simply unset the object and exits the function if the response is not a resource.

I hope this solution and explanation is helpful.

[wilt]

hi,

Thanks for the report. I'll test this against our code and look to implement for v139

[Zola]

hi,

Thanks for the report. I'll test this against our code and look to implement for v139

That would be just great, was this the right place to post it? I wasn't sure of whether I should put it here or in the code section.

You can verify this very easily.

On your test installation, turn on E_ALL and go into the query factory and do

echo "<pre>";
print_r($obj);
echo "</pre>";

at the end of the Execute() class.

When you look at any page where it's echoed out, you will see the [resource] field changes from something like "resource_id #123" to a plain 1, then you will see the error get echoed out.

It happens after the first instance of a non-recordset returning query, and I caught the whole update/delete thing because I added code to echo the query that was producing the non-resource result to find out which statement was the culprit.

I'm very glad to have a Zen programmer look at it, I don't believe there are any non-recordset queries in the application that need the object, and what I did should not interfere in any way with error handling, but still, I don't know the app backwards and forwards like you guys do.

[lbeachmike]

Hi there -

I came across this error as well after upgrading my server from php 4->5.

Is ZenCart 1.3.8a known to run successfully on php 5? (Specifically, 5.2.9)

I see lots of announcements about php 5 support as of Feb 2008, but I've found no further code releases. Is there a current CVS that is php 5 compatible that can be downloaded?

This is for a client account who also has a third party template, but it looks as if the ZenCart code is at least responsible for one or more of the critical errors.

Any help would be appreciated.

Thanks.

Mike

[DrByte]

Yes, out-of-the-box, Zen Cart v1.3.8a is capable of running on PHP 5.2.9.

If you encounter a problem as described earlier in this thread, you might find the posted code change to be of some potential benefit to you.


If you are having specific problems that are not answered elsewhere already, please post a new thread about those issues.

[lbeachmike]

Thanks for the quick response.

Yes, I am encountering the problem mentioned above, which appears to be a fatal error.

The above is helpful, although I am not sure which files contain the code and thus require manual updating. I'm also confused as to why I'm experiencing this if it is out-of-the-box compatible w/ 5.2.9.

I have found a thread with updated files for what appears to perhaps be a similar issue -

http://www.zen-cart.com/forum/showpo...0&postcount=10

Do you know of any thread with the necessary updated files for this particular issue?

Thanks again for your help.

Mike

[a_berezin]

Hi Zola,
Thank you for the explanation!
The solution needs to be fixed, because this solution could cause an application error.

After every appearance of the following lines:

$zp_db_resource = @mysql_query($zf_sql, $this->link);
if (!$zp_db_resource) $this->set_error(@mysql_errno(),@mysql_error());

add this:

if (!is_resource($zp_db_resource)){
  unset($obj);
  $time_end = explode (' ', microtime());
  $query_time = $time_end[1]+$time_end[0]-$time_start[1]-$time_start[0];
  $this->total_query_time += $query_time;
  $this->count_queries++;
  return $zp_db_resource;
}

[Website Rob]

I have found a thread with updated files for what appears to perhaps be a similar issue -

http://www.zen-cart.com/forum/showpo...0&postcount=10

The two issues seem to be of a different kind as the issue in this thread refers to file:

includes/classes/db/mysql/query_factory.php


There would appear to be 3 instances where the bug fix code would be applied.

127 $zp_db_resource = @mysql_query($zf_sql, $this->link);
128 if (!$zp_db_resource) $this->set_error(@mysql_errno(),@mysql_error());
>> enter bug fix code
129 $obj->resource = $zp_db_resource;

168 $zp_db_resource = @mysql_query($zf_sql, $this->link);
169 if (!$zp_db_resource) $this->set_error(@mysql_errno($this->link),@mysql_error($this->link));
>> enter bug fix code
170 $obj->resource = $zp_db_resource;

203 $zp_db_resource = @mysql_query($zf_sql, $this->link);
204 if (!$zp_db_resource) $this->set_error(mysql_errno(),mysql_error());
>> enter bug fix code
205 $obj->resource = $zp_db_resource;

Using bug fix code provided by Zola, would look like this:

$zp_db_resource = @mysql_query($zf_sql, $this->link);
if (!$zp_db_resource) $this->set_error(@mysql_errno(),@mysql_error());
if(!is_resource($zp_db_resource)) {
$obj = null;
return;
}
$obj->resource = $zp_db_resource;

My question is; "Which bug fix code is more elegant: Zola code or a_berezin code?"

I know Andrew is well familiar with coding for Zen Cart but Zola code would appear to be tested whereas Andrew never makes any mention of testing his code.