First of all, can you reference the related issues? Perhaps there's valuable information there.

Second of all, what is your database server and version, and what PHP version do you use?

"Note to get this far I had to perform the undocumented step of adding $g_database_version to the config ( itself yet another bug in the upgrade process, seriously did you guys not test this? )."

Question: Are you currently using 1.1.8 from debian ? At least at one point, they replaced our installation/upgrade procedure with their own, so did not include the database version information.

Nope locally I'm running XAMPP on windows 7, we set it up on the server via FTP

I checked in the downloads for 1.1.8 to see if that variable was present in the sample config and couldn't find it

Apologies for the delay, I have the environment set up at my work machine:

PHP Version 5.2.6
MySQL 5.0.67
Apache 2

Installed from XAMPP, running under windows 7 x64, using a root mysql user

Of note: http://www.mantisbt.org/forums/viewtopic.php?f=2&t=10830

Although that user is upgrading from a much earlier version, the changes suggested if they work, should be applied

Person with a similar issue who decided to nuke the DB and install afresh ( not possible in my case ):

http://www.mantisbt.org/bugs/view.php?id=6014

I just did a quick test here

• install 1.1.2 from scratch, login as admin, create project and test issue
• install 1.2.8, copy config_inc.php from 1.1.2
• execute admin/install.php
  Schema was upgraded successfully, without any errors. So the process works for me.

So it would be interesting to know, what you did and what problems/error messages you encountered before applying that "undocumented step"...

If I coment out the definition of that variable, I fail one of the checks:

Config File Exists but Database does not POSSIBLE PROBLEM
Bad config_inc.php?

If I uncomment it, the check passes, and the install form changes into an upgrade form. Removing the DB user+pass so it uses the default leads to:

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) )ENGINE=MyISAM DEFAULT CHARSET=utf8
Table 'mantis_bug_file_table' already exists

Of note, I do not see that variable defined in the sample config included with 1.2.8

Also, the database does exit, and I have a working 1.1.2 install running off of said database

Config File Exists but Database does not POSSIBLE PROBLEM

means that install.php was not able to connect to your database using the provided credentials.

(and consequently the attempt to retrieve the current schema version from the mantis_config_table, failed)

I'd suggest to double-check in the config_inc.php present in your 1.2.8 directory, the values of
$g_hostname
$g_db_username
$g_db_password
$g_database_name
$g_db_type

hmmm I have this in my config_inc.php:

$g_hostname      = 'localhost';
$g_db_username   = 'root';
$g_db_password   = '--redacted--';
$g_database_name = 'bugtracker';
$g_db_type       = 'mysql';

I use identical login and hostname on numerous Wordpress sites and MySQL Query Browser ( albeit different database names.

As a test I nuked the tables in that database and reloaded install.php, and it said the same Config File Exists message. I then proceeded with a fresh install, and it works, albeit I now have a fresh empty mantis, and all my data is gone until I put my db backup up again and I'm back where I started.

So the issue is not the connection to the database, the install script will happily create a new fresh install with the same config and DB details

So let's assume your connection information in config_inc.php is indeed correct.

Can you confirm what happens if you copy this file to your 1.2.8 installation as-is, then navigate to the login page (e.g. http://yourhost/mantis128/login_page.php)

If your setup is indeed correct, you should see the login page with a warning: "The database structure may be out of date. Please upgrade here before logging in.". Report results or any errors.

I get:

APPLICATION ERROR 0000401
Database query failed. Error received from database was 0001146: Table 'bugtracker.mantis_category_table' doesn't exist for the query: SELECT c.*, p.name AS project_name FROM mantis_category_table AS c
LEFT JOIN mantis_project_table AS p
ON c.project_id=p.id
WHERE project_id=0
ORDER BY c.name .

I'm currently working on redoing the database export and import from the live site, just to be sure about things

I'm surprised the login page would query the category table - looks like a redirect to another page. Can you make sure you're logged out (logout_page.php) ? Setting $g_show_detailed_errors = ON; may also help.

I found some issues regarding the file table, dropped all the tables locally, changed mysql packet size to 16MB from 1MB, put the backup in full, having sorted the issues out from before, so now the local database is a verified perfect replica of the remote DB.

Re-ran tests with new DB import, same results, no upgraded database =(

Ah, loaded in incognito mode I get a login dialog, with the usual "Warning: Admin directory should be removed." message

Here's the database version row in mantis_config_table:

'database_version', 14, 0, 90, 1, '63'

loaded in incognito mode
Not sure what you mean by that

I get a login dialog, with the usual "Warning: Admin directory should be removed."
Yes, that's expected.
No other warnings below that (like the one mentioned in 0013450:0030123) ?

'database_version', 14, 0, 90, 1, '63'
"14" is project_id, should normally be 0 (all projects). Can you try changing this value ?

Incognito mode, aka private browsing in google chrome. I logged out and tried it in normal mode too with the same result ( no other warnings )

Anyways, I modified the value from 14 to 0 as requested, and ran the upgrade script at admin/install.php, SUCCESS!! Update succesful, I now have a working install of 1.2.8 running locally.

Thus I can verify it was the project id being non-zero

Someone must have manually changed this value in the manage configuration view or directly in the database.

Anyway, glad you're up and running now.

Thanks for the help =]

@dregad: that was some nice sleuthing you did there :-) Perhaps there's some sort of check we can perform against database_version so we don't get thrown off balance by an invalid configuration setting?

@rombert, thanks :-)

Regarding an additional check: considering after verification that this variable actually can't be set from the GUI in the manage configuration page (since it's not defined in config_defaults_inc.php), as far as I can tell the only way to change it is by direct SQL update.

So it could definitely be done, but the question is, is it worth the effort?

(In reply to comment 0013450:0030134)

So it could definitely be done, but the question is, is it worth the effort?

Not sure, hopefully this does not show up again...