I have an action in a model that adds a record to a table. It works fine when I test it by typing values in to the browser, but is failing when I test it with PHPUnit. The frustrating part is that I don't really know how to diagnose the problem.
The unit test has a (rather long) $data array, and the problem occurs when I call the dbTable->insert($data) method. The log shows:
CRIT (2): Application Error
CRIT (2): Request Parameters
How can I get more information on these errors? The line following the offending line is not executed.
Thanks!
Ok, so I had a boolean field in the DB that was not nullable. It showed a default value of 0, so I assumed that I didn't need to provide this field in the insert statement. Seems I was wrong.
As soon as I provided a value for this field it worked fine.
Something else that confused this issue is that I had assumed I'd get a more descriptive error in my log if was such a simple error ...
Related
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.
Transformation Parse Warning [<<P M Parse Warning>> <<Invalid constant sun-expression>> <<Expression Error>> [TO_DATE]:invalid string for converting to Date
… t:TO_DATE(s:s:”,s:s:’YYYYMMDD’)
……….
AND SATIS_TARIHI = >>>> TO_DATE($$RUN_DATE,’YYYYMMDD’)<<<<];
How can I solve this?
This is the first time I encounter this error. Normally, this is a daily routine for our job. The parameter is successfully added to the mapping and all the other things seem okay. I’d appreciate your help.
I tried to start the workflow and got this error.
You need to define a $$RUN_DATE in mapping. Currently its not defined in mapping or its null in parameter file.
You need to set a default value in mapping like 20221221 for today.
Or else you can set it up in a parameter file like this
[folder.workflow_name]
[folder.session_name]
$$RUN_DATE=20221221
Considering this is your daily routine and up till now it has been working fine, I assume this is not a new development and no recent changes have been made. Apparantly PowerCenter got an invalid value for the parameter.
Check you parameter file and how it gets generated.
Was the process of generating paramfile executed without issues?
Was there enough storage space?
Can you verify the paramfile contents?
Can you regenerate it?
Can you modify it and provide some value manually?
Feel free to get back with some updates for more help if your problem won't get resolved by checking the items on the list above.
Site works fine. Suddenly it will through an error. When clicking "flush system cahce" the error will go away for a some time. Anything from minuttes to severaæ hours.
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1247602160:
Unknown column 'tx_my_domain_model_formular.rel_formular' in 'where
clause' |
TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException
thrown in file
/webserver/typo3/src/6.2.15/typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php
in line 862.
It is correct that the columns does not exist. But how to preceed in finding the error after this? Where is the sql generated that causes the site to crash?
UPDATE
A check "myParentObj->getChildObj instanceof myChildObjClass" used to work just fine. After changing myParent model to lazy load the ChildObj, then the class of childObj changed from childObjClass to a lazyLoadClass... I am not sure but I guess that is in turns somewhere somehow caused the core error seen in the log.
How to investigate further I simply cannot work out. Eg. store all DB calls in a file og DB to analyze after the error occours.
First
Please take time to write a good question. For a good question you'll get a good answer. It doesn't have to be perfect (not everyone is a native english speaker) but please reread your question.
Answer
If all fields are defined correctly, just run a DB compare from within the installtool.
If not, you need to define the DB-fields in your extension correctly.
Is this your own extension? When doing the query that triggers the error you could call execute(true) to generate the actual SQL statement and debug from there.
Hello and thanks for your time!
While trying to implement the Form Wizard I ran into a couple of problems.
Using xdebug showed up that all submitted data is lost, what means:
$this->data, $_POST and $params['data'] / ['form'] are all empty.
It seems that cake is doing some kind of redirect / dispatching and the actions are called twice. When I set a breakpoint in the beforeFilter() method, I can see all data filled in properly.
There were some suggestions in other discussions that this could be caused by invalid links in the layout, but using an empty layout didnt change anything.
I also removed the Auth Component, the RequestHandler, Helpers to see if theres something happening... nothing.
Problem is, Im quite new to Cake and have no further ideas where to look.
Currently Im getting this Warning:
Warning (512): Step validation: daten is not a valid step. [ROOT/plugins/wizard/controllers/components/wizard.php, line 271]
Code | Context
return $this->controller->autoRender ? $this->controller->render($this->_currentStep) : true;
} else {
trigger_error(sprintf(__('Step validation: %s is not a valid step.', true), $step), E_USER_WARNING);
$step = "daten"
WizardComponent::process() - ROOT/plugins/wizard/controllers/components/wizard.php, line 271
SignupsController::wizard() - ROOT/plugins/bookings/controllers/signups_controller.php, line 18
Dispatcher::_invoke() - CORE/cake/dispatcher.php, line 204
Dispatcher::dispatch() - CORE/cake/dispatcher.php, line 171
[main] - ROOT/webroot/index.php, line 83
Dont think that helps much, cause the $step array is also lost.
Any idea deeply appreciated! :)
The issue is that the session has expired and the information is lost that the system keeps tracking progress and data with. Set your session to be longer in the security preferences in the core config. This still doesn't stop the error though. To fixed that replace:
trigger_error(sprintf(__('Step validation: %s is not a valid step.', true), $step), E_USER_WARNING);
to:
$this->reset();
This will send the user back to the first part of the form wizard. You will have lost all the user data but that happened by the session expiring in the first place or if someone tries to jump to a form which hasn't been accessed yet by using the form, it will also reset. This could be a good security measure or just plain annoying.
Anyway, that is my solution, there could be better ones.
I've tried the SugarCRM forums for this problem as well, but I was wondering if anyone here has run into a similar issue and would be willing to share the solution.
We are working with the SOAP API for Sugar CRM via the Sugar On Demand system and their appears to be a problem - which at the moment looks very much like a bug.
The Module we trying to work with is the case module. We are running the set_entry action on the case module. It worked the first time we did this, but now it refuses to allow us to enter any more modules. I've checked the log files and made sure that we are submitting anything in the case_number field to over ride this, but whenever we try to add a new case we get the following error showing up in the log:
Query Failed: INSERT into cases set id='bb53030e-0f2f-5787-f403-4dde57cde36e', name='New RMA Request Test', date_entered='2011-05-26 13:37:15', date_modified='2011-05-26 13:37:15', modified_user_id='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', created_by='b1256ced-011d-7c1a-e1f3-4d4004ea4e9a', description='fjdlkas', deleted='0', assigned_user_id=null, team_id=null, team_set_id='ded0fbb0-c5dc-74ee-0622-4d22eb653a80', type=null, status=null, priority=null, resolution=null, system_id=1, work_log=null, account_id=null: MySQL error 1062: Duplicate entry '2147483647' for key 2
This is a bit odd for a few reasons:
I've confirmed that the corresponding key is auto-incrementing.
I am not submitting that number anywhere.
The next auto-increment value when I check the setting in the Studio is actually 2147483648.
Can someone explain what I need to do with the SOAP API to stop it from overriding the auto-increment value on my table?
Edit: I get the same error if I try to add a case via the interface, so I suspect this could be a problem with the CRM configuration itself rather than a SOAP related issue like I originally thought.
I would try to increase the size of the case_number field from an int(11) to something bigger and see if that fixes the issue.