In my local/development environment, the MySQLi query is performing OK. However, when I upload it on my web host environment, I get this error:
Fatal error: Call to a member function bind_param() on a non-object in...
Here is the code:
global $mysqli;
$stmt = $mysqli->prepare("SELECT id, description FROM tbl_page_answer_category WHERE cur_own_id = ?");
$stmt->bind_param('i', $cur_id);
$stmt->execute();
$stmt->bind_result($uid, $desc);
To check my query, I tried to execute the query via control panel phpMyAdmin and the result is OK.
TL;DR
Always have mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); in your mysqli connection code and always check the PHP errors.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your MySQLi code produces an error like mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given..., Call to a member function bind_param()... or similar. Or even without any error, but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. In the older PHP versions such errors weren't transferred to PHP, and all you'd get is a cryptic error message mentioned above. Hence it is very important to configure PHP and MySQLi to report MySQL errors to you. And once you get the error message, fixing it will be a piece of cake.
How to get the error message in MySQLi
First of all, always have this line before MySQLi connect in all your environments:
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
After that, all MySQL errors will be transferred into PHP exceptions. An uncaught exception, in turn, makes a PHP fatal error. Thus, in case of a MySQL error, you'll get a conventional PHP error. That will instantly make you aware of the error cause. And the stack trace will lead you to the exact spot where the error occurred.
How to get the error message from PHP
Here is a gist of my article on PHP error reporting:
Reporting errors on a development and live servers must be different. On the development server it is convenient to have errors shown on-screen, but on a live server error messages must be logged instead, so you could find them in the error log later.
Therefore, you must set corresponding configuration options to the following values:
On a development server
error_reporting should be set to E_ALL value;
log_errors should be set to 1 (it is convenient to have logs on a development PC too)
display_errors should be set to 1
On a production server
error_reporting should be set to E_ALL value;
log_errors should be set to 1
display_errors should be set to 0
After that, when MySQL query fails, you will get a PHP error that explains the reason. On a live server, in order to get the error message, you'll have to check the error log.
In case of AJAX call, on a dev server open DevTools (F12), then Network tab. Then initiate the request which result you want to see, and it will appear in the Network tab. Click on it and then the Response tab. There you will see the exact output. On a live server check the error log.
How to actually use it
Just remove any code that checks for the error manually, all those or die(), if ($result), try..catch and such. Simply write your database interaction code right away:
$stmt = $this->con->prepare("INSERT INTO table(name, quantity) VALUES (?,?)");
$stmt->bind_param("si", $name, $quantity);
$stmt->execute();
Again, without any conditions around. If an error occurs, it will be treated like any other error in your code. For example, on a development PC it will just appear on-screen, while on a live site it will be logged for the programmer, whereas for the user's convenience you could use an error handler (but that's a different story which is off topic for MySQLi, but you may read about it in the article linked above).
What to do with the error message you get
First of all you have to locate the problem query. The error message contains the file name and the line number of the exact spot where the error occurred. For the simple code that's enough, but if your code is using functions or classes you may need to follow the stack trace to locate the problem query.
After getting the error message, you have to read and comprehend it. It sounds too obvious if not condescending, but learners often overlook the fact that the error message is not just an alarm signal, but it actually contains a detailed explanation of the problem. And all you need is to read the error message and fix the issue.
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, and letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
If you don't understand the error message, try to google it. And when browsing the results, stick to answers that explain the error rather than bluntly give the solution. A solution may not work in your particular case, but the explanation will help you to understand the problem and make you able to fix the issue by yourself.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. The same goes for the absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advise extremely useful.
A list of things you should never ever do in regard of error reporting
Never use an error suppression operator (#)! It makes a programmer unable read the error message and therefore unable to fix the error
Do not use die() or echo or any other function to print the error message on the screen unconditionally. PHP can report errors by itself and do it the right way depends on the environment - so just leave it for PHP.
Do not add a condition to test the query result manually (like if($result)). With error exceptions enabled such condition will just be useless.
Do not use the try..catch operator for echoing the error message. This operator should be used to perform some error handling, like a transaction rollback. But never use it just to report errors - as we learned above, PHP can already do it, the right way.
P.S.
Sometimes there is no error, but no results either. Then it means, there is no data in the database to match your criteria. In this case you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again.
I've got an article that can help in this matter, How to debug database interactions. Although it is written for PDO, the principle is the same. Just follow those instructions step by step and either have your problem solved or have an answerable question for Stack Overflow.
Related
Problem
The JSON is returned correctly encoded but json_last_error equates to 5 thus Laravel throws this exception on response creation in JsonResponse->setData().
Related References
A resolved bug report for symfony and PHP 7.3: https://github.com/symfony/symfony/issues/31447 mentions this exact issue. That is:
If a json_encode()/json_decode() without JSON_THROW_ON_ERROR encoding option set throws an error, any subsequent call to the same with that flag set will not reset the error of the previous call.
The JSON_THROW_ON_ERROR RFC mentions this behavior as by design: https://wiki.php.net/rfc/json_throw_on_error
Unfortunately Laravel's code uses the flag but does not cater for this behavior and throws exception if json_last_error() returns a non zero value. Which in this case should have been ignored as it will always reference the previous error. Perhaps a version check should be added.
Investigation
I have also searched the bowls of my application and haven't found the misbehaving json_encode/json_decode without JSON_THROW_ON_ERROR set so I am sure it is internal to Laravel before Middleware calls.
Additional Context
This suddenly started happening today in our server. It happens when users connect to the server through the web app from select systems. Even though system kind should not affect server side response generation but still web app always generates this error for specific PCs/Mobiles.
Proposed Hack
After sifting through the Symfony bug report, the easiest workaround I have found is to just clear the error through an inconsequential json_encode('1') call. Which effectively resets the error code to 0 and the later JSON methods work fine.
Fortunately we have our own response generation class so just adding this before the hand-off to Laravel works fine.
Still this is a hack. I am more interested in a better solution or any bug fix available.
I created this policy using the generator, however I still get an error:
edit: I have used the policy generator again, reducing the actions, here is my updated script obtained with that tool, I assume that at least the syntax is correct:
I have then removed one action at a time, starting with s3:CreateBucket at this point I get a different error: Action does not apply to any resource(s) in statement same if I only leave the s3:DeleteObject and s3:GetObject actions.
At some point earlier on it appears there were too many sql connections and the following was echo'd to screen for whomever was looking:
PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[08004] [1040] Too many connections' in /dir/file.php:21
Stack trace:
#0 /dir/file.php(21): PDO->__construct('mysql:host=loca...', 'the user', 'password')
As you can see, it printed the username and password.
I'm new to PDO form of connecting to db, and I got into it because people told me my regular mysql_connect form was insecure. However by default, when mysql_connect ever had too any connections it never printed the username and password to the screen.
What a disaster.
How do I stop PDO from doing this if it error's out??
I'm using:
$dbh = new PDO('mysql:host=localhost;dbname=' . $db, $user, $pass);
PDO is not doing anything of the sort.
This is happening because you are not performing any exception handling, so the default PHP error handler is being invoked and showing your call stack, including function arguments.
Usually call stacks are a very good thing, so you want the error handler to work; you just need to use it properly.
Place try/catch blocks in relevant places around code that can throw exceptions; at the very least, put a catch-all try/catch block around your code's top-level so that nothing seeps through.
PDO documentation, though, clearly states (in a red warning box) the big risk you take not properly catching PDO exceptions:
If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler().
(http://www.php.net/manual/en/pdo.connections.php)
Edit your php.ini and set
display_errors = 0
If you don't have access to php.ini then at the top of your script(s) you need to add:
ini_set("display_errors", "0");
See http://php.net/manual/en/errorfunc.configuration.php and http://php.net/manual/en/function.error-reporting.php
This will stop all errors from being outputted to the browser. Make sure you are still logging errors (via php.ini setting).
P.S. Do not toss away PDO
Is there any way to get a string variable of error message shown in Execution result tab of a package.???
Please help.!
If you are looking for a way to log the information/warning/error messages then you can make use of SSIS logging feature.
Please refer my answer in this Stack Overflow question to understand how to configure the logging feature.
SSIS logging will capture all the messages that are shown in the Execution Results tab. You can also configure it to log the messages that you are interested in.
Hope that helps.
Though this question has already answered i would like to add few points to the question being asked.
Is there any way to get a string variable of error message shown in Execution result tab of a package.
Assume you encountered an error in your SSIS package, now all we need to log that error into your own table (other than SSIS catalog DB's), you can create a Execute SQL task with the INSERT script parameterized. Paramerter you need to use in Parameter Mapping tab is System::ErrorDescription.
INSERT INTO LOG_TABLE(ID,ERROR,ERROR_TIMESTAMP) VALUES(1,?,GETDATE());
Note: You can utilize other System Variables like PackageName,MachineName etc to log into the table.
Please refer screenshot below:
I have installed the sfErrorNotifierPlugin. When both options reportErrors/reportPHPErrors reportPHPWarnings/reportWarnings are set to false, everything is ok. But I want to catch PHP exceptions and warnings to receive E-mails, but then all my tasks fail, including clear-cache. After few hours of tests I'm 100% sure that the problem is with set_exception_handler/set_error_handler.
There's a similar question:
sfErrorNotifierPlugin on symfony task but the author there is having problems with a custom task. In my case, even built-in tasks fail.
I haven't used sfErrorNotifierPlugin, but I have run into 'The “default” context does not exist.' messages before. It happens when a call is made to sfContext::getInstance() and the context simply doesn't exist. I've had this happen a lot from within custom tasks. One solution is to add sfContext::createInstance() before the call to sfContext::getInstance(). This will ensure that a context exists.
There's an interesting blog post on 'Why sfContext::getInstance() is bad' that goes into more detail - http://webmozarts.com/2009/07/01/why-sfcontextgetinstance-is-bad/
Well, the problem could not be solved this way, unfortunately. Using sfErrorNotifierPlugin, I have enabled reporting PHP warning/errors (apart from symfony exceptions) and this resulted in huge problems, e.g. built-in tasks such as clear-cache failed.
The solution I chose was to load the plugin only in non-task mode (project configuration class):
public function setup()
{
$this->enableAllPluginsExcept('sfPropelPlugin');
if ('cli' == php_sapi_name()) $this->disablePlugins('sfErrorNotifierPlugin');
}
WHen a task is executed, everything works normally. When an app is fired from the browser, emails are sent when exception/warning occurs (maybe someone will find it useful).
Arms has explained the problem correctly. But usually context does not exist when executing backend/maintenance tasks on the console. And it is easier if you handle the condition yourself.
Check, if you really need the context?
If you do, what exactly do you need it for?
Sometimes you only want a user to populate a created_by field. You can work around by hard-coding a user ID.
If you want to do something more integrated, create a page (which will have a context) and trigger the task from there.
you can test the existance of the instance before doing something inside a class. Like:
if(sfContext::hasInstance())
$this->microsite_id = sfContext::getInstance()->getUser()->getAttribute('active_microsite');
I've been experiencing the same problem using the plugin sfErrorNotifier.
In my specific case, I noticed a warning was raised:
Warning: ob_start(): function '' not found or invalid function name in /var/www/ncsoft_qa/lib/vendor/symfony/lib/config/sfApplicationConfiguration.class.php on line 155
Notice: ob_start(): failed to create buffer in /var/www/ncsoft_qa/lib/vendor/symfony/lib/config/sfApplicationConfiguration.class.php on line 155
So, checking the file: sfApplicationConfiguration.class.php class, line 155,
I've replaced the ' ' for a null, then the warnings disappears, and also the error!
ob_start(sfConfig::get('sf_compressed') ? 'ob_gzhandler' : ''); bad
ob_start(sfConfig::get('sf_compressed') ? 'ob_gzhandler' : null); good