Hmm, I just browsed some other bugs on that subject and found that I should use /admin/install.php instead. So after running install.php & entering the required information, I get an error telling me that "mantis_config_table" already exists. Please see the second screenshot for that.

Ok, and finally I found that comment 16805 from 0008808 looks like exactly where I fail now.

In 0008808 giallu mentions that the problem could be due to running install.php after having run upgrade.php before. So I dropped & recreated my mantis test install & ran /admin/install.php right as the first script, yet still no change.

This may be a problem in the debian installer. I've referred it to the packager for help.

Hi,

I am the maintainer of mantis for Debian. Indeed there are known issues with upgrading from a debian installation to 1.1.x which about I already nagged thraxisp 2 weeks ago :) Well, the reply (and the solution) were yet outstanding.

I must confess, that the mantis developers and I have some different opinions about how (database) upgrades should be handled. Therefore the current upgrade path (as I use it) is quiet hackish in the sense that I'm using the Print SQL Queries function in the upgrader to generate SQL statements for the package-integrated update routine and therefore must hope that the sql statements generated are right, but cannot be sure.

However due to this bug report thraxisp came back to me, asking if I can confirm that the mantis_config_table is not created due to upgrading. But I can't confirm this. Just to give a status in between.

Best Regards,
Patrick

Thanks for your responses so far.

From the devel list I am aware of the different opinions on how (major) upgrades should be handled, yet the only thing that counts at the end is if the upgrade works at all. And in that case it seems that it is not working at all in my case(tm).

But back to my problem:

First I am not upgrading using any debian package, because there is none yet for 1.1.1. Instead I am using the tar.gz downloadable from sf.net.

However, from my debian 1.0.8 installation I do have a mantis_config_table, but it lacks the "database_version" entry, so maybe that's the problem:

mysql> select * from mantis_config_table where config_id='database_version';
Empty set (0.00 sec)

mysql> select count() from mantis_config_table;
+----------+
| count() |
+----------+
| 9 |
+----------+
1 row in set (0.00 sec)

The following command is missing from the Debian 0.19 to 1.0.6 MySQL upgrade script:

INSERT INTO mantis_config_table ( value, type, access_reqd, config_id, project_id, user_id ) VALUES ('52', 1, 90, 'database_version', 20, 0 );

Running this command and then running the admin/install.php should upgrade your installation.

hmm, I am afraid that inserting the row does not change anything. I am still stuck with the same message as before:

------CUT-------
BAD
CREATE TABLE mantis_config_table ( config_id VARCHAR(64) NOT NULL, project_id INTEGER NOT NULL DEFAULT 0, user_id INTEGER NOT NULL DEFAULT 0, access_reqd INTEGER DEFAULT 0, type INTEGER DEFAULT 90, value LONGTEXT NOT NULL, PRIMARY KEY (config_id, project_id, user_id) )TYPE=MyISAM
Table 'mantis_config_table' already exists
------CUT-------

Ok, digging a bit deeper inside admin/install.php I found this:

line 137 in core/constant_inc.php looks like this:
----CUT----
define( 'ALL_PROJECTS', 0 );
----CUT----

line 668 in in admin/install.php line 668 looks like this:
----CUT----
$t_last_update = config_get( 'database_version', -1, ALL_USERS, ALL_PROJECTS);
----CUT----

lines 95 to 105 in core/config_api.php look like this:
----CUT----
$query = "SELECT config_id, user_id, project_id, type, value, access_reqd FROM $t_config_table";
$result = db_query( $query );
while ( false <> ( $row = db_fetch_array( $result ) ) ) {
$t_config = $row['config_id'];
$t_user = $row['user_id'];
$t_project = $row['project_id'];
$g_cache_config[$t_config][$t_user][$t_project] = $row['type'] . ';' . $row['value'];
$g_cache_config_access[$t_config][$t_user][$t_project] = $row['access_reqd'];
}
----CUT----

In other words, for the 'database_version' config parameter, $g_cache_config is populated like this:
$g_cache_config['database_version'][0][20] = "1;52"

lines 113 to 118 in core/config_api.php look like this:
----CUT----
while ( ( list( , $t_project ) = each( $t_projects ) ) && ! $t_found ) {
if ( isset( $g_cache_config[$p_option][$t_user][$t_project] ) ) {
$t_value = $g_cache_config[$p_option][$t_user][$t_project];
$t_found = true;

@@ debug @@ echo "clu found u=$t_user, p=$t_project, v=$t_value ";

}
}
----CUT----

That said, it is obvious that 'database_version' is not found for the "ALL_PROJECTS"-project (ALL_PROJECTS = 0) because in your statement from comment 16924 above database_version is explicially registered for project_id 20.

So either core/config_api.php needs to be extended to test for ALL_PROJECTS as well or the INSERT statement is wrong.

And indeed, after changing the INSERT statement from above to ...
----CUT----
INSERT INTO mantis_config_table ( value, type, access_reqd, config_id, project_id, user_id ) VALUES ('52', 1, 90, 'database_version', 0, 0 );
----CUT----

... the upgrade works.

sigh Indeed, this works for installations that were upgraded from 0.19x to 1.0.x and are now to be upgraded to 1.1.x. Unfortunately the solution is a bit different is probably a bit different if upgrading from 1.0.x to 1.1.x.
However, it is disappointing that it is like it is, because it is not a problem with the packaging, but with the stupidity of having features that simply do not work as expected. In this case the problem results from using the "Print SQL queries instead of executing"-function, which is part of mantis since ages. That seemed to work, since all my test installations got upgraded successfully with the resulting SQL-commands. However, as thraxisp stated in a mail a few days ago: "It doesn't work". The question I ask myself is: Why do you keep this feature then? Even now the install.php has a "Print SQL statements" function. But it is printing bullshit: While it upgrades the database just fine if the "Print"-function is not used, it prints SQL statements that create already existing tables. A shame. If you don't want it to be part of mantis and if you don't like to support it, then please remove it. Or flag it "useless" or something like this at least.

daudo, you are correct. I made an error in the SQL command.

I checked the repository for both 1.1.x and 1.2.x, both include the line setting the 'database version' parameter as the last line of the printed SQL queries.

It appears that the Debian Etch (1.1.2) installer forgets to set this config entry as well. I'll add a bug downstream.

No, thats wrong. First of all: Debian Etch does not contain mantis at all. Second: The bug with the missing database_version has been fixed in 1.1.2 version of the package. The SQL statements for the upgrade include:

INSERT INTO mantis_config_table VALUES ('database_version',0,0,90,1,'63');

A similar statement is executed on installation.
According from what I could get from a plain-source-installation this is the right value for that.

I'm getting this same problem upgrading Mantis from 1.1.1 to 1.2.0a2.
I've tried the git snaphot from Tue, 18 Nov 2008 08:29:47 and had no change...

I need to use 1.2x because I want to integrate SVN and Git with Mantis.

The insert statement doesn't worked, because in my case that line already exists. I tried to change the version to 52 as adviced on issue 0009798 and didn't worked, got the same error message.
I know a litlle bit of PHP, but is really hard to debug this...

Hint: It is possible to delete rows before adding them.

Yeah, right...
When I updated that row the result was be the same as deleting and adding it again...
I've just updated the different values...

I drop this table and try to do the update again and got another error:
"Operand type clash: int is incompatible with text" para a consulta: "INSERT INTO mantis_config_table
( value, type, access_reqd, config_id, project_id, user_id )
VALUES
(?, ?, ?, ?, ?,? )"

I've checked the database and the table is there again.
I found a lot of users facing this problem on MS SQL Server since January, so I'm considering to use MySQL instead...

Allan,

If you drop me an email to paul@mantisforge.org I can probably help you out. I run mssql at work using odbc_mssql as the database driver.

Paul

I'm marking this issue as resolved, as from what I can tell, daudo's original case related to mysql and is now working.

If i'm incorrect in this please reopen so we can help you out.

Thanks
Paul

well, just for the archaeologists that will once dig out this bug: it was not mysql related but a problem with the debian package instead.

Hi! We can't reopen, so I'll just add some notes.

1) 0008808 is related to this issue as well I think
2) I tried upgrading my MySQL-based install from 1.0.1 to 1.1.6 with the tar archive from sourceforge, using the guidelines in the documentation (install.php).

That didn't work out of the box. I got the above mentioned

BAD
CREATE TABLE mantis_config_table...

error. Logical, since that table already exists, as do all the following to-be-created tables.

I had to use the 'Print SQL queries instead of executing' and skip the CREATE TABLE and INDEX statements and only apply the queries after those.

This of course, leaves me wondering whether everything is upgraded. I should check the CREATE TABLE queries with what I had in de database, but as the later queries change the mentioned CREATE TABLE queries, I guess that it's ok...

But I could only come up with this yet-to-be-tested solution after reading the manual, some forum posts, and finally this issue (and the related issues)...

That is not as it should be I think?

Eric,

If this issue is due to a fault debian package - please contact debian to see if they have released a fixed package. They are probably in a better position to identify what parts of the database schema our install scripts generate were missed by their package.

Paul