View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011909 | mantisbt | upgrade | public | 2010-05-11 08:02 | 2011-04-05 14:23 |
Reporter | smig1o | Assigned To | dhx | ||
Priority | normal | Severity | block | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.1 | ||||
Target Version | 1.2.5 | Fixed in Version | 1.2.5 | ||
Summary | 0011909: Database query failed - problems with ticket revisions | ||||
Description | I get when I try to see bug with modified description. | ||||
Steps To Reproduce |
| ||||
Additional Information | I was trying to find where the problem is and found out that | ||||
Tags | No tags attached. | ||||
Same problem here after upgrading from 1.1.8 to 1.2.1 |
|
Quick'n'dirty fix: function bug_revision_exists( $p_revision_id ) { in core/bug_revision_api.php Seems to do the trick for us. Thanks, smig1o, for tracking the problem down. [edit: fixed stupid copy&paste error] |
|
I did same 'quickfix'. But I am waiting for official patch. |
|
I had the same problem, upgrading from 1.1.6 to 1.2.1 |
|
We have the same problem, after migration from 1.2.0a3 to 1.2.1: APPLICATION ERROR 0000401 |
|
I reinsert the error message with a space after the # so error codes are not escaped like bug ids: APPLICATION ERROR # 401 |
|
In my case, for some reason during the installation the database was not upgraded, so the mantis_bug_revision_table was not created and the dates were not migrated (i always saw the default date 1970-1-1) |
|
dhaun, i got same problem, you path works fine. Thank you |
|
This problem still exists in Mantis 1.2.4. My above workaround "fixes" the problem for now, but could someone from the Mantis team please comment on this issue? |
|
I filed a bug @ 0012513 which contains a more technical reason to why this issue is a problem. The comment from this bug (which I have now resolved as a duplicate of this one) is: Within history_api, the history_localize_item function is calling the bug_revision_exists function of bug_revision_api with the wrong argument type. It should be sending an integer, not a string. As bug_revision_api doesn't use db_prepare_int when building queries this error will result in SQL query execution errors when an integer field in the database is compared to the supplied string (type mismatch). This is in the patch queue now :) |
|
Committed. |
|
MantisBT: master 730f7298 2010-12-24 22:04 Details Diff |
Fix 0011909: history_localize_item sending wrong argument type to bug_revision_exists Within history_api, the history_localize_item function is calling the bug_revision_exists function of bug_revision_api with the wrong argument type. It should be sending an integer, not a string. As bug_revision_api doesn't use db_prepare_int when building queries this error will result in SQL query execution errors when an integer field in the database is compared to the supplied string (type mismatch). |
Affected Issues 0011909 |
|
mod - core/history_api.php | Diff File | ||
MantisBT: master-1.2.x 68e56f26 2010-12-24 22:04 Details Diff |
Fix 0011909: history_localize_item sending wrong argument type to bug_revision_exists Within history_api, the history_localize_item function is calling the bug_revision_exists function of bug_revision_api with the wrong argument type. It should be sending an integer, not a string. As bug_revision_api doesn't use db_prepare_int when building queries this error will result in SQL query execution errors when an integer field in the database is compared to the supplied string (type mismatch). |
Affected Issues 0011909 |
|
mod - core/history_api.php | Diff File |