Mantis Logo
Mantis Manual
Manual
Installation
Requirements
Backups
Upgrading
CVS Integration
Uninstall

Partner Links
Upgrading
Last Modified: October 5, 2005 14:10PM
(This page contains a new upgrade method effective after release 1.0.0.)
Description

!!! ALWAYS BACKUP CODE, DATA, AND CONFIGS BEFORE UPGRADING !!!

This includes your Mantis directory, your attachments, and your database.

Unless you are familiar with PHP, it is not recommended to use non-released versions of Mantis (i.e. CVS versions). These versions are not tested for general use and there might not be an easy upgrade path for the next release from such intermediate versions.

It is preferable to create a new directory for each release. This ensures that all files are intact and that there is a path to downgrade your installation, if you need to. Generally for minor versions upgrade (eg: 0.17.3 to 0.17.5) you can just copy over the old code. You may want to backup up your current config_inc.php and any customizations in custom_strings_inc.php, custom_constants_inc.php, and custom_functions_inc.php that you may have made.

NOTE: The default configuration file can be located under Mantis main folder with the name config_defaults_inc.php. You can override these configurations by adding config_inc.php which should include only the configuration variables that you want to change from the defaults.

Mantis will first pull the default values, then pull the site specific values. This way you will gain the new global variables but not have to continually reset your core settings. It is best to leave the default file alone. It is recommended to take a few minutes and create a minimal config_inc.php file that contains only values that are different from the config_defaults_inc.php file. Email values, database settings, path values, and any settings different from the defaults should go in here.

Upgrading
  1. Log out of the system before upgrading
  2. Indicate to users that the system is in an offline mode by

    cp mantis_offline.php.sample mantis_offline.php

  3. First, transfer the file to your webserver using whatever method you like
    best (ftp, scp, etc). You will need to telnet/ssh into the server machine for
    the next steps.
  4. Next, untar/gunzip it to the directory that you want.
    The usual command is (1 step):
    tar zxvf <filename.tar.gz>
    OR (2 steps):
    gunzip <filename.tar.gz> tar xvf <filename.tar>

    Note the name of the mantis source directory that is created. It should be of the form "mantis-release" (e.g., mantis-1.0.0rc1). Winzip, Stuffit, and other programs should also be able to handle decompression of the archive.
  5. Copy the configuration files (config_inc.php, custom_strings_inc.php, custom_constants_inc.php, and custom_functions_inc.php) to the new directory to preserve your settings.

  6. Next we will update the necessary database tables.

    If you are upgrading from a pre-1.0.0 (including 1.0.0a* or 1.0.0rc*) installation to 1.0.0, access http://yoursite/mantis-release/admin/upgrade.php. This will upgrade your database to 1.0.0. Once your database has reached release 1.0.0, you can use the method listed below.

    From your web server, access http://yoursite/mantis-release/admin/install.php

    This page will walk through the following steps:
    1. check basic parameters for the web server
    2. Confirm the database type and location, and a database user/password
      pair. For update, an administrative user/password pair can also be
      provided. The operating user requires ALTER, SELECT, INSERT, and UPDATE
      privileges. For installation or upgrade, INDEX, CREATE, DELETE, and DROP privileges are
      also required.
    3. update the database and tables.
    4. perform some post installation checks on the system.
  7. You can load up http://yoursite/mantis-release/admin/check.php to see if you set things up correctly.
  8. At this point you may want to rename the directory to something simpler like
    'mantis'. You will use the mv command to rename a directory (Windows users
    substitute the "ren" command or use explorer).

    mv mantis mantis-old mv mantis-release mantis
User Contributed Notes
Upgrading		 Add Notes About Notes
victor @ mantis
30-Oct-2003 13:49		 #16
To go to the page with the upgrade scripts go to:

http://www.example.com/mantis/admin
Click "Upgrade your installation"
Click "Upgrade now"

Going to upgrade.php directly will only show you one part of the upgrade process.
eric_seppanen@mailinator.com
26-Jan-2004 16:27		 #60
If you notice that all your strings (in bug descriptions, bugnotes, news, etc.) have funny backslash escapes now ( " becomes \" and ' becomes \'), you probably need to go to the /admin page and run the string escape fix.

Seems like this would be a required upgrade step, but for some reason isn't documented here and is kept separate from the other upgrade steps.

More info in bug #3537:
http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=3527
cembree-removethis@ZEROSPAMSez-as.net
28-Jan-2004 11:50		 #63
While upgrading from 7.5 to 8.0 I had to manually launch admin\upgrade_advanced.php in order to modify the MySQL tables. Every time I tried to use the other methods, I saw that none of the fixes were applied.

I'll post a correction if I type-o'd the filename... I'm getting old ya know.
mantis@NOkipuSPAM.co.ukNOSPAM
13-May-2004 17:40		 #133
I found that after upgrading from .17 to .18 all references in the (old) emails were wrong. I fixed it by adding a file called "view_bug_page.php" containing:

<?
Header("Location: bug_view_page.php?bug_id=".$_GET["f_id"]);
?>
idsinghj@natlab.research.philips.com
07-Sep-2004 9:44		 #198
Hi where using mantis 0.17.3 and wanted to upgrade to 0.19.0rc
We use:
 
Apache web server V1.3.31
MySQL database server V4.1.3 Beta
PHP V4.2.2

I used the update script coming with the package but encoutered a problem. the script could not create the mantis_filter_table. of the 0.18 update package.

It gave an sql error (Value "ID" was incorrect).
I looked at the code and discovert an bug.

Old SQL Statement:

CREATE TABLE $t_filters_table (
   id int(7) unsigned DEFAULT '1' NOT NULL auto_increment,
   user_id int(7) NOT NULL,
   project_id int(7) NOT NULL,
   is_public BOOL,
   name char(64) NOT NULL,
   filter_string text NOT NULL,
   PRIMARY KEY (id))"
);

New SQL Statement:


CREATE TABLE $t_filters_table (
   id int(7) unsigned NOT NULL auto_increment,
   user_id int(7) NOT NULL,
   project_id int(7) NOT NULL,
   is_public BOOL,
   name char(64) NOT NULL,
   filter_string text NOT NULL,
   PRIMARY KEY (id))"
);

Now the script workes fine!



 
 
zachromans@hotmail.com
22-Nov-2004 17:01		 #267
it will not let me get on msn messanger because of a soft ware fire wall or other program is prevanting msn messanger from accessing the internet
bcl@brianlane.com
19-Apr-2005 19:34		 #414
When upgrading from 0.19.2 to 1.0.0a1 I needed to change mantis_config_table columns config_id, project_id and user_id to be NOT NULL before the final SQL patch would apply (setting PRIMARY KEY).

bcl
jwa at javatopia dot com
10-Jun-2005 15:10		 #463
I upgraded from 0.18.3 to 1.0.0a3, and now I get:

Database query failed. Error received from database was #1064: You have an error in your SQL syntax near 'on cft.id = cfpt.field_id
JOIN mantis_project_table as pt on' at line 3 for the query: SELECT distinct cft.id as id, cft.name as name
FROM mantis_custom_field_table as cft
JOIN mantis_custom_field_project_table as cfpt on cft.id = cfpt.field_id
JOIN mantis_project_table as pt on cfpt.project_id = pt.id
LEFT JOIN mantis_project_user_list_table as pult
on cfpt.project_id = pult.project_id and pult.user_id = 2
JOIN mantis_user_table as ut on ut.id = 2
WHERE pt.view_state = 10 OR
( pt.view_state = 50 and pult.user_id = 2 ) OR
( pult.user_id is null and ut.access_level >= 90 )
ORDER BY name ASC

when I try to do just about anything. All of the upgrade scripts ran just fine. The admin check.php script returns okay.
frederic_leroy@yahoo.com
13-Jun-2005 14:30		 #466
I get the same error message on Join sql syntax. It appears in a lot of queries.

I'm using mysql 3.23.58, i installed it via rpm (yum) on FC2.
maksimov-at-gmail-dot-com
14-Jun-2005 20:58		 #471
Same thing here. Seems that there's problem related to custom fields tables (not updated or something?) I'll try to look at it now
maksimov-at-gmail-dot-com
14-Jun-2005 22:05		 #472
Okay, I've spent too much time trying to understand why MySQL doesn't like those JOINs when they seem to be absolutely up to spec. So I've just went one version back to 1.0.0a2 which does work fine.
thraxisp.at.magma.ca
16-Jun-2005 10:45		 #474
The join problem is mySQL 4.0 syntax, not 3.xx. See #5689 in the bug tracker for a solution.
mx@NO_SPAMorimos.com
22-Jun-2005 10:25		 #482
Have anyone tried to upgrade from 0.17.5 to 1.0.0a3?
When I try to run the upgrade script, almost every fourth query fails and the script aborts (then you have to go back, uncheck all failed upgrades, ...).
In addition some neccesary upgrades are not in the list (field 'failed_login_count' in mantis_user_table is missing for example).

Do I have to upgrade to another version, eg. 0.1.8, first?

Micha
simon@NOSPAMPLEASEprimalseeds.org
24-Jun-2005 12:14		 #487
regarding the bug tracker #5689 rev 1.53 system_field_api.php, where do you get it from to change it please?
blesstiti@yahoo.com
04-Aug-2005 2:59		 #552
Anybody upgrade from Mantis 0.17.3 to 1.0.0rc1 before? Can email me?
I would like to know if:

1. Performance and speed wise is a lot faster? Currently using 0.17.3 seems quite slow in loading the page.

2. If just to do basic task, to assign bug, resolve, is the upgrade necessary?

tks!
grzegorz.kaczor ^AT ^ cc.com.pl
17-Aug-2005 4:29		 #567
When I upgrade from 0.19.2, mantis tries to create tables that already exist!

mantis_bug_table
mantis_bug_history_table

GK
usenabuse@chandlerpages.com
17-Aug-2005 13:47		 #571
Same here, as far as I can tell, there is no way to keep your current data and upgrade -- you have to start a new table.
That's silly, of course, but I've worked it from every angle and it just tries to create a table that already exists.
usenabuse@chandlerpages.com
17-Aug-2005 14:17		 #572
The forums have the following help:

Could you find the value of a row in the mantis_congif_table where config_id = 'database_version'? Deleting this row should activate the older #222288">upgrade.php program.

This worked for me. Although you can't do the recommended upgrades unless you delete the entry again.
squirrelzm@xinhuanet.com
23-Aug-2005 1:01		 #576
I have same promble with #567. It does not upgrade the database, it only install it?? why? I want upgrade it from 0.19 to 1.0rc1.
yourname@NOSPAMyourdomain.com
14-Sep-2005 2:56		 #606
We found that clicking the RSS link gives an "Access Denied." error, even for Admins.
jwa@javatopia.com
25-Sep-2005 14:53		 #622
I successfully upgraded from 0.18.3 to 1.0.0 RC2 using the installation steps on this page. Excellent work!! I have a database that uses custom fields, which were a problem in a prior upgrade path. That has been fixed in the 1.0.0RC2 release.

MySQL v10.8 release 3.23.22-beta
PHP 4.3.2
RH Linux 7.0
dingfelder
06-Oct-2005 16:17		 #639
it would be nice to have release specific upgrade details.

For instance, Upgrading from R1 to R2 is (I assum) much easier than from old versions.

At minimum, we need notes detailing the upgrade proceedure for 2 scenerios:

1. from the last version to the newest one
2. from an old version to the newest one

If the processes are the same, then indicate so, if they are different then we should detail how.

Why do we need this?

It is quite frustrating to have to go through unnecessary steps!
For instance, if the newest release does not require a DB change, I dont want to have to read or be concerned about about DB backups and DB scripts to run for upgrades from old versions. (although, yes I of course do nightly DB backups)

Additionally, it would be very nice to have an easily accesssable "change log" of what files changed in which versions, so that if we make custom changes to files, we know which ones need to be overwritten (since they changed in the new release)
omatichyn
13-Oct-2005 6:15		 #646
I cannot upgrade my 0.19 version to 1.0.0rc1
I use http://localhost/admin/install.php
but error appears
BAD
CREATE TABLE mantis_bug_file_table ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, bug_id INTEGER UNSIGNED NOT NULL DEFAULT 0, title VARCHAR(250) NOT NULL DEFAULT '', description VARCHAR(250) NOT NULL DEFAULT '', diskfile VARCHAR(250) NOT NULL DEFAULT '', filename VARCHAR(250) NOT NULL DEFAULT '', folder VARCHAR(250) NOT NULL DEFAULT '', filesize INTEGER NOT NULL DEFAULT 0, file_type VARCHAR(250) NOT NULL DEFAULT '', date_added DATETIME NOT NULL DEFAULT '1970-01-01 00:00:01', content LONGBLOB NOT NULL, PRIMARY KEY (id) )TYPE=MyISAM
Table 'mantis_bug_file_table' already exists

upgrade script tryes to create existing table. How I can workaround this proplem?
thanks in advance for answer
pcholt at gee mail
30-Oct-2005 23:44		 #687
Confirming that omatchin's problem with BAD CREATE TABLE mantis_bug_file_table ( ... ) still occurs when following this procedure to upgrade from 0.19.2 to mantis-1.0.0-rc3.
remoter@0x539.cc
31-Oct-2005 2:02		 #688
yes, i also got this problem.
updating Mantis 0.19.2 -> Mantis 1.0.0rc2
are there any sql script i can execute manualy ???
holli72_at_web_dot_de
01-Nov-2005 0:50		 #692
If you try to upgrade from an older version than 0.16-14, you could get an error: "Table 'mantis.mantis_bug_monitor_table' doesn't exist for the query: DESCRIBE mantis_bug_monitor_table" (probably thrown by the function config_get_global).

To solve this, you could do the following things:

1. comment the following two lines in the file admin/db_tables_names_inc.php like:
# $t_bug_monitor_table = config_get_global( 'mantis_bug_monitor_table' );
# $t_bug_relationship_table = config_get_global( 'mantis_bug_relationship_table' );

2. do the upgrade, you will get an sql error: "near '( source_bug_id ..." because of the missing table names. create the tables manually (e.g. at mysqlcc) by executing following sql commands (mysql syntax):

# Upgrade 0.16-14: Create bug relationship table
CREATE TABLE IF NOT EXISTS mantis_bug_relationship_table ( source_bug_id int(7) unsigned zerofill NOT NULL default '0000000', destination_bug_id int(7) unsigned zerofill NOT NULL default '0000000', relationship_type int(2) NOT NULL default '0');
# Upgrade 0.16-15: Create bug monitor table
CREATE TABLE IF NOT EXISTS mantis_bug_monitor_table ( user_id int(7) unsigned zerofill NOT NULL default '0000000', bug_id int(7) unsigned NOT NULL default '0');

3. Now, reactivate the commented lines above (1.) and do the rest of the upgrade by executing upgrade again.
iuhh
09-Nov-2005 6:47		 #709
I have succssfully upgraded our v0.17.3 to 1.0.0rc3. A very important thing that I've noticed, is that you'll need to apply the 'String Format Fix' before upgrade, otherwise the new mantis will display the escaped escape characters - i.e. garbage.

There is no use to apply the string format fix after you've done the basic upgrade.
prashant@consolidated.ab.ca
09-Nov-2005 16:29		 #712
When I go to admin/ and choose to upgrade, upgrade.php gives me an error:

Fatal error: Call to undefined function error_parameters() in /usr/local/apache2/htdocs/mantis/core/config_api.php on line 143

the same happens with upgrade_escaping.php

Any ideas?
anonymous@anonymous.com
29-Nov-2005 23:41		 #739
Upgrading from 1.0.0rc2 to 1.0.0rc3 is very simple. The only affected files are:

./bug_sponsorship_list_view_inc.php
./lost_pwd.php
./core/filter_api.php
./core/html_api.php
./doc/ChangeLog

So replace those new files in your mantis directory and set
$g_mantis_version = '1.0.0rc3';
inside config_defaults_inc.php
tsoheili@gmail.com
01-Dec-2005 18:39		 #741
When trying to upgrade from .19 to 1.0rc3 I get that same crazy problem with mysql trying to create tables instead of update them. Please someone let me know WTF is going on. :)


Thanks,
Tim
tbonefox#at#free.fr
27-Dec-2005 9:29		 #788
Hi,

upgrading from 0.19.3 to 0.19.4, MySQL5, Apache 2, it's OK.

just this point: the url to upgrade is http://server/mantis-0.19.4/admin/upgrade.php and not install.php as described

today, the 1.0.0rc4 is not available to download, will try later.

Christophe.
tibor[at]inventasoft.hr
03-Jan-2006 10:27		 #802
I'm trying to upgrade from 0.18.3 to 0.19.4.

Before this, I've succesfully migrated an existing 0.18.3 installation from Linux to a Win2k3 server, with PHP 5.1.1 and mySQL 5.0.18

So, I have a functional "mantis_old" dir with version 0.18.3, and a "mantis" dir with 0.19.4. When I run the "Basic Upgrade Set" (upgrade.php) - nothing ever happens - I get no feedback, just a blank page in my browser, with "done" in the status bar.

Any help?
I'd appreciate a reply to the e-mail, thanx.
tbonefox#at#free.fr
06-Jan-2006 10:32		 #807
feedback for #692

trying to upgrade from 0.19.4 to 1.0.0rc4

the procedure works to the 4th point.

when I uncomment both lines and apply the upgrade script a second time I have this:
Drop votes column of mantis_bug_table
0.17-jf-8
ERROR: Can't DROP 'votes'; check that column/key exists

Christophe.
jwa@javatopia.com
03-Feb-2006 16:19		 #864
I upgraded from 1.0rc2 to 1.0rc5 and noticed that it was faster and the filters are more reliable. The upgrade process was seemless. The "Change Log" doesn't seem to do anything yet, though.
sati.mutlu@gmx.net
07-Feb-2006 8:36		 #869
when i want to update from mantis 0.19.0 to 1.0.0:

BAD
CREATE TABLE mantis_bug_file_table ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, bug_id INTEGER UNSIGNED NOT NULL DEFAULT 0, title VARCHAR(250) NOT NULL DEFAULT '', description VARCHAR(250) NOT NULL DEFAULT '', diskfile VARCHAR(250) NOT NULL DEFAULT '', filename VARCHAR(250) NOT NULL DEFAULT '', folder VARCHAR(250) NOT NULL DEFAULT '', filesize INTEGER NOT NULL DEFAULT 0, file_type VARCHAR(250) NOT NULL DEFAULT '', date_added DATETIME NOT NULL DEFAULT '1970-01-01 00:00:01', content LONGBLOB NOT NULL, PRIMARY KEY (id) )TYPE=MyISAM
Table 'mantis_bug_file_table' already exists

have anybody an idea?
mantis_spam@DELETEerifCAPS.org
07-Feb-2006 20:48		 #879
Upgrading from .18.x to 1.0.0 --

upgrade.php kept redirecting me to install.php, which made me at first think that was what was supposed to be happening, where I got the same error as the user above (the bug file table already existed, but it was trying to create it)

Commenting out:

        //$upgrade_set->add_items_with_check( 'upgrades/0_13_inc.php', $t_project_table );
        //$upgrade_set->add_items_with_check( 'upgrades/0_14_inc.php', $t_bug_file_table );
        //$upgrade_set->add_items_with_check( 'upgrades/0_15_inc.php', $t_bug_history_table );
        //$upgrade_set->add_items_with_check( 'upgrades/0_16_inc.php', $t_bug_monitor_table );

in admin/upgrade_inc.php

made the real upgrade page show up. After that, you _shouldn't_ run /admin/install.php -- everything should just magically work. ((you did copy your config files over from the old mantis, right?))

The clue was this comment:

    # this upgrade process was introduced in 0.17.x, so beyond here, the
    # process of checking the upgrade_table to see if updates are applied should work
should_be_optional_but@cantsubmit.without.it
08-Feb-2006 13:21		 #882
I've got my 0.19 version upgrade to 1.0 despite the table create errors. I chose the option to generate SQL instead and pasted that to a file. I then launched Mantis 1.0 - hit an error about a missing field, so I checked against the SQL and added it. Run again, missing table, added it. Seemed to work, but one missing field when I chose View, added that and no problems since (fingers crossed). The items I added were:

//mantis_user_table - this was a rename of an existing field
lost_password_request_count SMALLINT NOT NULL DEFAULT 0,

// this was missing completely
CREATE TABLE mantis_project_hierarchy_table (
child_id INTEGER UNSIGNED NOT NULL,
parent_id INTEGER UNSIGNED NOT NULL
)TYPE=MyISAM;

// mantis_bug_table added this field
sticky TINYINT NOT NULL DEFAULT 0,

There may be more, but these are the only changes I've needed so far.

I'm surprised about the lack of an official solution to this major problem, particularly as it has happened throughout several release candidates. Can anyone find a comprehensive SQL diff between 0.19 and 1.0?
mantis_spam@DELETEerifCAPS.org
14-Feb-2006 13:27		 #892
One thing I forgot to note in my solution above--if you erroneously attempted to actually run the INSTALL when UPGRADE redirected you, you'll need to drop all the tables and do a restore (note, just doing a restore won't drop the tables that were just created, and that will keep you bouncing back to the install page).

As to the person just above me, you could build a sql diff out of the various upgrade scripts (they're in a directory all by themselves), but you might as well just let the system work. It's kind of nice when it finally does. ;)
Upgrade from .19 to 1.0.0 gone wrong...
14-Feb-2006 22:30		 #895
I get the same error as above (table already exists) when (supposedly) upgrading the database. I tried editing the SQL as suggested, but the changes were already there.

Surely there must be a SQL script somewhere to upgrade a .19 database to 1.0.0???

HELP ME PLEASE!

MatthewHayes_at_comcast.net
17-Feb-2006 13:45		 #899
If anyone is interested, I have created the exact SQL code to migrate your MySQL database from 0.19.4 to 1.0.0. I used a test database and used diff viewer to fine tune the SQL to be sure the final result will be exactly like the 1.0.0 MySQL tables (minus 1 MyISAM table comment that didn't seem important).

If you would like a copy, email me directly (since there doesn't seem to be a file upload utility here) and I'll send it to you.

If you're migrating from a different version, you can probably take what I have and tweak it a little.
kbaccam@free.fr
24-Feb-2006 10:40		 #904
Mantis release 0.19.3 -> 1.0.0

Before clicking on the button "install/upgrade", i've replaced all string 'CreateTableSQL' to 'ChangeTableSQL' in file mantis-release/admin/schema.php :

$upgrade[] = Array('CreateTableSQL',... to $upgrade[] = Array('ChangeTableSQL'

It seems work but can someone confirm ?
mstod@nosam.myorg.com
26-Feb-2006 8:42		 #906
After upgrading to 0.19.2 to 1.0.1, I could not add a reminder, got the following:

APPLICATION ERROR #401
Database query failed. Error received from database was #1054: Unknown column 'note_type' in 'field list' for the query: INSERT INTO mantis_bugnote_table
(bug_id, reporter_id, bugnote_text_id, view_state, date_submitted, last_modified, note_type, note_attr )
VALUES
('415', '2','739', '10', '2006-02-26 05:21:33','2006-02-26 05:21:33', '1', '|9|2|5|4|')
 

I had to add note_type and note_attr to the mantis_bugnote_table, but guessed on type. Can someone tell me WTF these field types are?
christoph.schroeder@NOSPAMcard-1.com
03-Apr-2006 5:40		 #973
It's just custom_constant_inc.php not custom_constants_inc.php i think.
offputATgmailDOTcom
12-Apr-2006 16:10		 #997
While upgrading from 0.19.2 to 1.0.1 we had errors like other people had. we tried to change the schema.php file's CreateTableSQL commands to ChangeTableSQL and that worked to stop the error but it had a different error later in the script because it tried to add a new administrator to the database. Technically you should delete the 'administrator' account so most responsible administrators shouldn't have troubles with this technique. But if you hadn't deleted the default account, you must before running the upgrade.php script or it will fail midway. I can't vouch for the exactitude with which this works as we haven't delved fully into the end result yet but it seemed to work based on a cursory glance.
Ola
12-Apr-2006 19:02		 #999
I'm trying tupgrade from 1.0.0rc2 to 1.0.0 with no luck - keep bouncing back to install page when I want to run upgrade.php. Tried the solutions mentionet above with commenting out from upgrade_inc.php and resetting the database. No luck.

Are there any database changes from 1.0.0rc2?
kukovec@iskratel.si
19-May-2006 5:26		 #1075
Hi guys!

I'm writting this so it may be helpful to others. I had mayjor problems when upgrading from Mantis 0.19.1 to 1.0.3. I did everything as instructed in the manual while upgrading. I could login and view issues, but many things didn' work like:

If I go to My View and click link "Assigned to me", "Reported by me", etc. and get

Database query failed. Error received from database was #1364: Field 'expiry' doesn't have a default value for the query: INSERT INTO mantis_tokens_table

and similar errors. JpGraph is also not working related to database query failed problems.

SOLUTION (a little time consuming, but it works)

1. Install new Mantis 1.0.3 (just exstract the files to your desired place).
2. Create new database in mysql.
    login to mysql server: mysql -hlocalhost -uroot -ppassword
    create database: create database bugtracker;
    exit mysql server: quit;
3. Import old database.
    mysql --force -uroot -ppassword bugtracker < old_database.sql
4. Go trough upgrade procedure with new_mantis/admin/upgrade.php
5. This upgrade does not do its job properly so we have to do the following.
7. Create backup of this database with
    mysqldump --opt -uroot -ppassword bugtracker > temp_database.sql
8. Delete and recreate bugtracker database
    login to mysql server: mysql -hlocalhost -uroot -ppassword
    create database: d rop database bugtracker;
    create database: create database bugtracker;
    exit mysql server: quit;
9. Create backup of this empty database with
    mysqldump --opt -uroot -padmin bugtracker > empty_database.sql
10. Take your intermediate database dump temp_database.sql and new empty database dump empty_database.sql
11. Merge databases with some merge tool (Araxis merge, etc.).
12. Merge temp_database.sql to empty_database.sql. Do not merge every thing, just INSERT startements. Other sturcure stays the same.
13. Save empty_database.sql to proper_database.sql
14. Import proper database.
    mysql --force -uroot -ppassword bugtracker < proper_database.sql
15. Now new Mantis 1.0.3 should work properly with all your data from old database.
info@gradus.ch
30-May-2006 12:00		 #1103
the field expiry in the table mantis_tokens_table must have default value "null". this isn't after upgrading. there is a mistake in the file:ädmin/0_10_inc.php on line 37: NOT NULLL instead of NULL and default(NULL)
dunkel@calamus.net
14-Jun-2006 11:10		 #1137
Upgrading from 0.18.3 or 0.19.0 to 1.0.3 worked fine for me with the given advices and scripts, without any changes to files, as of today.

Thank you for doing an excellent debugging job.
tbonefox---free.fr
04-Aug-2006 6:37		 #1213
Hi guys,

A quick feedback if someone else needs one more.
I just upgrade our mantis servers from a 0.19.4 to a 1.0.5 release.

Things I did (as said above, thanks guys), 'CreateTable' -> 'ChangeTable' into admin/schema.php

I had to do:
- before the upgrade, I must trash the mysql/data/ib_logfile* and ibdata*
- after the upgrade, I must modify the field 'expiry' in the table 'mantis_tokens_table' to avoid error #1364: set the default value to NULL

Softwares: Apache 2.0.49, PHP 4.4.1, MySQL5 (old password setting), JPGraph 1.20.4

Thanks guys.
jwa@javatopia.com
19-Sep-2006 15:35		 #1262
Just upgraded to Mantis 1.0.5 and copied my config_inc.php from my 1.0.3 installation over to the new one. Found that the config_inc.php file contains the version declaration! Would it be possible to put "system" configuration data in a file that would not get clobbered during an upgrade?
should_be_optional_but@cantsubmit.without.at
24-Nov-2006 5:06		 #1304
upgrading from 0.19.2 to 1.0.6 (after upgrade from mySQL 4 to 5):

1. I edited the admin/upgrade.php and uncommented the following block to prevent the redirection to install.php and force upgrade.php to run:

# if ( -1 != config_get( 'database_version', -1 ) ) {
# if ( OFF == $g_use_iis ) {
# header( 'Status: 302' );
# }
# header( 'Content-Type: text/html' );
#
# if ( ON == $g_use_iis ) {
# header( "Refresh: 0;url=install.php" );
# } else {
# header( "Location: install.php" );
# }
# exit; # additional output can cause problems so let's just stop output here
# }

2. Call http://my.mantis/admin/upgrade.php -> upgrade from 0.x to 1.0 (all green)
3. Call http://my.mantis/admin/install.php -> upgrade from 1.0 to 1.0.6 (all green)
4. Call http://my.mantis/admin/check.php -> check if everything is OK (should be...)
Add Notes About Notes
Last updated: Wed, 20 Aug 2008 - 5:36:12

Mantis @ SourceForge