Page 1 of 1

ERROR after mantis + EmailReporting upgrade [RESOLVED]

Posted: Mar 28, 2017 4:28 am
by yoan
Hello,


Mantis is failing after a double upgrade :

I upgraded Mantis from 1.2.17 with (EmailReporting 0.9.0) to 2.0.1 (it's OK)
and after this I installed EmailReporting 0.9.1 in new version

And application says :
APPLICATION ERROR #401

Échec de la requête de base de données. L'erreur renvoyée par la base de données était #1146 : Table 'mantis_merge.mantis_plugin_EmailReporting_msgids_table' doesn't exist pour la requête : DELETE FROM mantis_plugin_EmailReporting_msgids_table WHERE NOT EXISTS( SELECT 1 FROM mantis_bug_table B WHERE B.id = issue_id ).
Merci d'utiliser le bouton « Précédent » de votre navigateur web pour retourner à la page précédente. Vous pourrez y corriger les problèmes identifiés par cette erreur ou choisir une autre action. Vous pouvez aussi choisir une option de la barre de menu pour aller directement dans une nouvelle section.
It's the same with command line :
PHP Notice: Use of undefined constant WAITED - assumed 'WAITED' in /opt/mantis_cdhit/mantisbt-2.0.1/config/config_inc.php on line 114
PHP Notice: Use of undefined constant PROGRAMED - assumed 'PROGRAMED' in /opt/mantis_cdhit/mantisbt-2.0.1/config/config_inc.php on line 124
PHP Notice: Use of undefined constant DELIVERED - assumed 'DELIVERED' in /opt/mantis_cdhit/mantisbt-2.0.1/config/config_inc.php on line 128
PHP Notice: Use of undefined constant TESTED - assumed 'TESTED' in /opt/mantis_cdhit/mantisbt-2.0.1/config/config_inc.php on line 130
PHP Notice: Use of undefined constant INSTALLED - assumed 'INSTALLED' in /opt/mantis_cdhit/mantisbt-2.0.1/config/config_inc.php on line 132
APPLICATION ERROR #401: Échec de la requête de base de données. L'erreur renvoyée par la base de données était #1146 : Table 'mantis_merge.mantis_plugin_EmailReporting_msgids_table' doesn't exist pour la requête : DELETE FROM mantis_plugin_EmailReporting_msgids_table WHERE NOT EXISTS( SELECT 1 FROM mantis_bug_table B WHERE B.id = issue_id ).
I forgted to do somthing ?


Thank you for your help :)

Re: ERROR after mantis + EmailReporting upgrade

Posted: Mar 28, 2017 11:30 am
by SL-Gundam
Did you delete or forgot the move the "mantis_plugin_EmailReporting_msgids_table" table required for EmailReporting?

I advise you do the following
  1. Update EmailReporting to 0.9.3 (https://www.mantisbt.org/wiki/doku.php/ ... lreporting)
  2. If you still have the same error, open the "configuration report" page in the MantisBT (Manage -> Manage Configuration -> Configuration Report) and delete "plugin_EmailReporting_schema". After that you will be required to upgrade the plugin again so that the schema will be created
  3. If after that you still have issues, get the latest version 0.10.0-DEV from Github

Re: ERROR after mantis + EmailReporting upgrade

Posted: Mar 29, 2017 4:32 am
by yoan
I found the mistach

In my DB (mysql) all tables are in lower case (secure configuration) and it's the same for older table mantis_plugin_emailreporting_msgids_table and plugin's request use table name : "mantis_plugin_EmailReporting_msgids_table"

I changed name of table in database with upper case charracters, it's ok, but i don't understand why there are upper case charracters in table name ?

It's resolved for me.

Re: ERROR after mantis + EmailReporting upgrade [RESOLVED]

Posted: Mar 29, 2017 11:47 am
by SL-Gundam
To my knowledge the secure configuration does not affect table naming (https://dev.mysql.com/doc/refman/5.7/en ... ation.html)

Did something change with your MySQL installation? I ask because there are configuration options which force lower case table names.
Table names might also be a specific issue between linux and windows. Linux is case sensitive when it comes to table names, windows is case-insensitive. This behavior can also be manipulated with configuration options
MantisBT table names are by-design lower case already. It could be that older versions of MantisBT plugin system converted project names in table names to lowercase. Which could have resulted in your situation if that behavior was changed... but i haven't checked whether this is true

At least i'm glad its fixed