Upgrading Database stuck at 75%

zackf · Post by **zackf** » Fri Nov 16, 2007 12:26 pm

I am upgrading from version 2.04 to 2.1.1 and everything seems to have gone ok but It is stuck at "Upgrading database, please wait.." at 75%.

Any smooth way I should terminate this process and start over? It said it could take up to 10 minutes but it's been about 25.

Thanks!

Post by **shaunw** » Fri Nov 16, 2007 12:58 pm

What database server/version are you using?

Is it possible for us to get remote access to your server to diagnose this? This is the second report we've had of a failed upgrade.

zackf · Post by **zackf** » Fri Nov 16, 2007 1:59 pm

I'm sorry about that,

I am using Fedora 7 with mysql 5.0.45. (We are evaluating the open source version right now, but will probably move to a CentOS machine if we move to using it a production envronment).

I backed up my timetrex database before I started so I have cancelled the upgrade, I went ahead and restored the old database and tried again with the same result. I can successfully test the connection before the upgrade starts and I can log into mysql as the timetrex user successfully. Apache is the owner of the /var/www/html/TimeTrex directory and all files/folders withing where my installation resides.

On this upgrade it has also asked me install php-gd which I did via yum before proceeding.

Just a thought, would the maintenace cronjob be affecting anything?

I am unable to open the system I am testing timetrex on to a public port right now so I cannot grant remote access, however I am somewhat familiar with things so if there is anything specific you are looking for I will be happy to get the info for you.

Post by **shaunw** » Fri Nov 16, 2007 2:12 pm

Good to hear that you made a backup, especially since you are using MySQL which lacks table change rollback functionality, so backups are essential.

If you edit:

interface/install/DatabaseSchema.php

Then uncomment the //Debug::setVerbosity(11); line.

Code: Select all

	case 'install_schema':
		//Need to create the tables after the database
		//exists and Database.inc.php has made a connection.
		//Otherwise we can't use objects yet.
	       Debug::setVerbosity(11);

Once you have done that, restore from your backup and proceed to run the installer again. This time you should see a whole bunch of debug output where the graph should be. (some of it may be hidden due to the iframe)

Simply click on the text, press CTRL+A to select it all, then paste here for us to take a look at.

zackf · Post by **zackf** » Fri Nov 16, 2007 2:33 pm

Post by **shaunw** » Fri Nov 16, 2007 2:36 pm

The tables would all be there from the first time you installed TimeTrex. However the upgrade process would modify some of those tables, so that is probably where the issue is arising.

Please follow my last post so we can get the debug output from the upgrade process and figure out exactly what is going on.

zackf · Post by **zackf** » Fri Nov 16, 2007 2:38 pm

(mysqlt): SHOW TABLES

Is the only result of the debug in the browser.

Post by **shaunw** » Fri Nov 16, 2007 2:48 pm

Is that all the text it shows, or is that all it can fit in the frame?

Just so you understand, there is a HTML frame that just fits the graph, so even though with debugging enable, it might output several pages of text, you may only see the first line, or first part of the line.

You need to click on the text, the press CTRL+A to select all the text, then you can copy and paste it into notepad, does it show more text then?

zackf · Post by **zackf** » Fri Nov 16, 2007 2:53 pm

Gotcha, I was not looking in the graph and text appeared as white so I did not see it at first. What I posted is what appears in the upper left hand corner of the browser, I suspect this is the output that makes more sense.

I removed several line breaks after <(mysqlt): SHOW TABLES > for space.

(mysqlt): SHOW TABLES

75 %
(mysqlt): SET AUTOCOMMIT=0 (mysqlt): BEGIN (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_T' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_T' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_T' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_T' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_T' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): SHOW TABLES (mysqlt): select * from system_setting where name = 'schema_version_group_A' (mysqlt): select company_id,user_id,section,name,value from permission where deleted = 0 order by company_id, user_id, section, name (mysqlt): CREATE TABLE permission_control ( id serial NOT NULL, company_id integer NOT NULL, name varchar(250) NOT NULL, description varchar(250) NOT NULL, created_date integer, created_by integer, updated_date integer, updated_by integer, deleted_date integer, deleted_by integer, deleted smallint DEFAULT 0 NOT NULL, PRIMARY KEY(id) ) Engine=InnoDB 1050: Table 'permission_control' already exists

ADOConnection._Execute(CREATE TABLE permission_control (
id serial NOT NULL,
company_id integer NOT NULL,
name varchar(250) NOT NULL,
descrip..., false) % line 861, file: adodb.inc.php
ADOConnection.Execute(CREATE TABLE permission_control (
id serial NOT NULL,
company_id integer NOT NULL,
name varchar(250) NOT NULL,
descrip...) % line 108, file: InstallSchema_Base.class.php
InstallSchema_Base._InstallSchema() % line 152, file: InstallSchema_Base.class.php
InstallSchema_Base.InstallSchema() % line 0, file:
call_user_func_array(Array[2], Array[0]) % line 94, file: InstallSchema.class.php

Post by **shaunw** » Fri Nov 16, 2007 6:51 pm

1050: Table 'permission_control' already exists

Did you restore from backup before you ran the installer again with debug enabled?

zackf · Post by **zackf** » Fri Nov 16, 2007 9:03 pm

Yes, like so:

Code: Select all

mysql -u timetrex -ptimetrex timetrex < /home/zackf/Desktop/timetrex.sql

zackf · Post by **zackf** » Fri Nov 16, 2007 9:31 pm

I dropped the timetrex database completely, re-added it, reset the permissions, then restored the backup - ran the installer and we're good to go.

Seems like the maintenace jobs are running more frequently than they used to, is this correct with the new version?

Apache's crontab still has the following entry:

* * * * * php /var/www/html/TimeTrex/maint/cron.php > /dev/null 2>&1

Post by **shaunw** » Fri Nov 16, 2007 11:25 pm

Yes, they need to run every minute, it has always been that way.

So, you restored from backup and now you were able to upgrade fine without any problems? Interesting...

zackf · Post by **zackf** » Sat Nov 17, 2007 12:49 pm

Yes, but only after I dropped timetrex from the database and re-created it. Interesting, but it reiterates the importance of backups! (If only I would listen to myself somtimes

TimeTrex Time and Attendance

Upgrading Database stuck at 75%

Upgrading Database stuck at 75%

Fixed

Time and Attendance