Avatar of Robert Saylor
Robert Saylor
Flag for United States of America asked on

php mysql pdo

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] 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.


$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.

Avatar of undefined
Last Comment
Julian Hansen

8/22/2022 - Mon
Robert Saylor

just noticed when I installed php rpm using yum it installed 5.3.3 that is most likely the issue
Ray Paseur

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Robert Saylor

Thanks Ray will try this in the morning. Been messing with it all afternoon.
Julian Hansen

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.
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
Ray Paseur

Instead of die(), a sturdier approach to visualizing errors is described here:

This is the same strategy that is illustrated in the article about MySQLi.
Julian Hansen

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.
Ray Paseur

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.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Julian Hansen

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 Saylor

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.
Log in to continue reading
Log In
Sign up - Free for 7 days
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Julian Hansen

Answer has no bearing on the question.

Recommend this question is deleted.
Your help has saved me hundreds of hours of internet surfing.
Ray Paseur

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.
Julian Hansen

Agree - that would have been my choice.