We help IT Professionals succeed at work.

php mysql pdo

Robert Saylor
on
247 Views
Last Modified: 2017-04-28
I installed a fresh google VM and getting odd errors on a common mysql command I use. The query works fine from shell but from the browser I get 500 error.

[Thu Apr 06 20:30:37 2017] [error] [client 108.168.152.134] PHP Fatal error:  Call to a member function fetch_assoc() on a non-object in /var/www/html/myfile.php on line 21

Open in new window


The issue is most likely in my server setup. I installed php using yum.

<?php
error_reporting(E_ALL);

$linkID5 = new mysqli('hostname', 'user', 'password', 'database');

        $tbl_name = "query_table_" . $_REQUEST['qbID'];
        //print "$tbl_name<br>";

        if ($_REQUEST['confirmed_lead'] == "yes") {
                $ts = date("U");
                $sql = "UPDATE `$tbl_name` SET `confirmed_lead` = 'yes',`confirmed_timestamp` = '$ts' WHERE `xxLeadId` = '$_REQUEST[xxLeadID]'";
                $result = $linkID5->query($sql);
        } else {
                // get columns
                $sql = "SHOW Columns FROM `$tbl_name` WHERE `Field` NOT IN ('id','date','system_timestamp','system_reposted')";
                $result = $linkID5->query($sql);
                $sql_top = "";
                $sql_bot = "";
                $date = date("Y-m-d H:i:s");
                $system_timestamp = date("U");
                while ($row = $result->fetch_assoc()) {
                        $field = $row['Field'];
                        $sql_top .= "`$row[Field]`,";
                        $sql_bot .= "'".$_REQUEST[$field]."',";
                }
                $sql_top .= "`date`,`system_timestamp`,`system_reposted`";
                $sql_bot .= "'$date','$system_timestamp','No'";

                $sql = "INSERT INTO `$tbl_name` ($sql_top) VALUES ($sql_bot)";
                //print "SQL: $sql";
                $result = $linkID5->query($sql);
        }

?>

Open in new window


This same code works on other servers just fine.
Comment
Watch Question

Robert SaylorSenior Developer

Author

Commented:
just noticed when I installed php rpm using yum it installed 5.3.3 that is most likely the issue
Most Valuable Expert 2011
Author of the Year 2014
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
Robert SaylorSenior Developer

Author

Commented:
Thanks Ray will try this in the morning. Been messing with it all afternoon.
CERTIFIED EXPERT
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
Also try putting this debug statement after line 16
if ($linkID5->error) {
  die("Error: {$linkID5->error}<br/>") ;
}

Open in new window

To see if the database is reporting any errors.
Note: using die() is not recommended for production applications - this is purely for debug purposes.
Most Valuable Expert 2011
Author of the Year 2014

Commented:
Instead of die(), a sturdier approach to visualizing errors is described here:
https://www.experts-exchange.com/articles/29115/PHP-Error-Handling-Never-Say-die-Again.html

This is the same strategy that is illustrated in the article about MySQLi.
CERTIFIED EXPERT
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
Just a note on die(). There are two scenarios to consider here

1. Writing sturdy code that gracefully handles errors in a production environment
2. Debugging code

The use of die in my last post was for the purpose of item 2 above. A temporary insert to determine the state of the application as part of determining why the logic of the application is not working. This is different from the application failing due to an unforeseen / unhandled condition in a production system.

Once the state of the DB is known through the error property and the code logic amended, the debug statement is removed.

Just to clarify the difference between my last suggestion and the good suggestions in Ray's article.
Most Valuable Expert 2011
Author of the Year 2014

Commented:
Once the state of the DB is known ... the debug statement is removed.
I actually never do that --  I never remove the error handler.  I have different approaches to displaying errors in deployed applications, but I always catch the errors/exceptions and always log the errors.

The reason for my strategy is that I often have clients who use shared hosting (I'm looking at you, GoDaddy) and these environments can and will have MySQL errors that arise from factors that are completely outside of the PHP scripts' control.  If you don't trap and identify the MySQL errors, you will have run-time failures with no evidence that points to the cause.  If you have an error_log file with the times, the queries, and the messages, you have a better chance of getting the hosting company to investigate and correct the conditions that lead to the error.  Example: Too many MySQL connections, or I/O error in the database server.  PHP can't do anything about those problems -- it can only report them to the application manager through the error_handler and the error_log.
CERTIFIED EXPERT
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
I actually never do that --  I never remove the error handler.
It is not an error handler - it is a debug statement. If you have a proper dev environment with a debugger you would step through your code and test the value you are looking for in the debugging environment. As PHP (for the most part) does not provide us with such tools - we use the debug output to check values in the script so that we can make decisions on code logic. Sometimes these debug statements turn into error handlers and sometimes they are simply removed. I am referring to the latter case.

Again I want to distinguish between unhandled errors that can occur in the wild and situations where your code logic bombs or does not do what it is supposed to do and you need to find out why so you can fix the logic - this is part of the development cycle.

Here is an example - I needed to find a particular path WP was taking in a site that was not behaving. I put die(__FILE__) statements in various suspected files and hit the site - gave me the info I wanted and I removed the die() statements as they had served their purpose.

In this particular case the application is erroring out due to error in code - insert die() to get the query error - check that is or is not the problem and remove the die - temporary solution for the purpose of gathering information.

I guess it comes down to personal preference - I use this technique successfully all the time - but none of my production code has die() anywhere in it - for the reasons you cover in your article.
Robert SaylorSenior Developer

Author

Commented:
I am creating a new VM image with CentOS 7 instead of 6.x

The query I know works something with the VM setup is wrong.
Senior Developer
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
CERTIFIED EXPERT
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
Answer has no bearing on the question.

Recommend this question is deleted.
Most Valuable Expert 2011
Author of the Year 2014

Commented:
The answer here shows how to do error visualization, which is what the author needed in this case.  I recommend this be the accepted answer, or at least the assisted answer.
https://www.experts-exchange.com/questions/29014567/php-mysql-pdo.html#a42082632
CERTIFIED EXPERT
Most Valuable Expert 2017
Distinguished Expert 2019

Commented:
Agree - that would have been my choice.