Upgrading to 5.1.0 - database upgrade won't finish

Ask your questions regarding TimeTrex installation here.
Locked
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

Yes I'm still using mysql against advice, but until now all upgrades have worked. This time it got to "Upgrading database, please wait... 97%" then stopped. Any advice? Running a linux server
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

I've been informed by the developers that in some cases, upgrading from certain versions of TimeTrex to the latest version can cause the upgrade to fail. They have released an updated build fixing this issue (its the same version though), so try downloading TimeTrex again and see if the upgrade succeeds.

Because you are using MySQL, its likely that you will need to restore from your latest backup prior to upgrading again to prevent other errors from occurring (this is an issue specific to MySQL, which is one reason we don't recommend using it).
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

I restored the database to a backup from before my upgrade attempt, then downloaded and installed TimeTrex_Standard_Edition_v5.1.0.zip. I enabled the installer and loaded ..../install/install.php. Everything proceeded but again the database upgrade pooped out at 97%. I then disabled the installer and logged in. I now see "WARNING: TimeTrex-Debug application version does not match database version. Please re-run the TimeTrex installer to complete the upgrade process." although TimeTrex still functions
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

We will need to see debug logs from TimeTrex during the install process.
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

Ok - I'll have to repeat the process with logging enabled. Something like this perhaps?

enable = TRUE
enable_display = TRUE
buffer_output = TRUE
enable_log = TRUE
verbosity = 11
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

Verbosity should be 10 rather then 11, otherwise the installer won't work.
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

Yes I discovered that about level 11:)

So I started again, fresh install of 5.1.0 and used a restored copy of the database from before my problems began. I got the same behavior as described above. The GUI screen showed:

Code: Select all

Debug Buffer
============================================================================
Memory Usage: 7500304 Buffer Size: 20
----------------------------------------------------------------------------
DEBUG [L0388] [7ms]: [Function](): URI: /TimeTrex_old/interface/install/DatabaseSchema.php?external_installer= IP Address: 192.168.3.100
DEBUG [L0390] [7ms]: [Function](): Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0
DEBUG [L0167] [50ms]: TTDate::setTimeZone(): Setting TimeZone: EST5EDT
DEBUG [L0085] [96ms]: [Function](): Bypassing Authentication
DEBUG [L0438] [99ms]: TTi18n::chooseBestLocale(): Choosing Best Locale...
DEBUG [L0446] [99ms]: TTi18n::chooseBestLocale(): Using Language from cookie: en_US
DEBUG [L0351] [99ms]: TTi18n::setLocale(): Generated/Passed In Locale: en_US
DEBUG [L0287] [100ms]: TTi18n::generateLocale(): Array of Locales to try in order for "en_US": en_US,en_US.UTF-8,en,en.UTF-8
DEBUG [L0245] [100ms]: TTi18n::tryLocale(): Found valid locale: en_US
DEBUG [L0354] [100ms]: TTi18n::setLocale(): Attempting to set Locale(s) to: en_US Category: 6 Current Locale:
DEBUG [L0360] [100ms]: TTi18n::setLocale(): Setting currency/numeric Locale to: en_US
DEBUG [L0373] [105ms]: TTi18n::setLocale(): Setting translator to normalized locale: en_US
DEBUG [L0393] [105ms]: TTi18n::setLocale(): Set Master Locale To: en_US
DEBUG [L0511] [105ms]: TTi18n::chooseBestLocale(): Using Locale: en_US
DEBUG [L1630] [110ms]: Misc::detectMobileBrowser(): User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 Retval:
DEBUG [L0109] [116ms]: Install::isInstallMode(): Install Mode is ON
DEBUG [L0337] [116ms]: Install::checkDatabaseExists(): Database Name: timetrex
DEBUG [L0347] [117ms]: Install::checkDatabaseExists(): Exists - Database Name: timetrex
DEBUG [L0379] [117ms]: Install::checkTableExists(): Table Name: company
DEBUG [L0389] [123ms]: Install::checkTableExists(): Exists - Table Name: company
============================================================================

============================================================================
                              PROFILER OUTPUT
============================================================================
Calls                    Time  Routine
-----------------------------------------------------------------------------
  1    618.5708 ms (82.57 %)  Main
 16    74.7101 ms (9.97 %)  __autoload
  1    7.5710 ms (1.01 %)  getEmptyRecordSet()
  1    47.0426 ms (6.28 %)  unprofiled

       1.2665 ms (0.17 %)  Missed
============================================================================
       749.1610 ms (100.00 %)  OVERALL TIME
============================================================================
and the timetrex.log contains:

Code: Select all

---------------[ 12-Dec-2012 16:12:02 -0500 (PID: 19107) ]---------------
DEBUG [L0390] [14ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [140ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [151ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [164ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [164ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [164ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
---------------[ 12-Dec-2012 16:12:02 -0500 (PID: 19107) ]---------------

---------------[ 12-Dec-2012 16:12:02 -0500 (PID: 19107) ]---------------
DEBUG [L0390] [14ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [107ms]:  <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [140ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [151ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [164ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [164ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [164ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
DEBUG [L0184] [165ms]:  <b>Debug::Text()</b>: Detected PHP errors (1), emailing log...<br>
DEBUG [L0184] [165ms]:  <b>Debug::Text()</b>: ---------------[ 12-Dec-2012 16:12:02 -0500 (PID: 19107) ]---------------<br>
---------------[ 12-Dec-2012 16:12:02 -0500 (PID: 19107) ]---------------

---------------[ 12-Dec-2012 16:13:01 -0500 (PID: 19142) ]---------------
DEBUG [L0390] [14ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [126ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [137ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [149ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [149ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [150ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
---------------[ 12-Dec-2012 16:13:01 -0500 (PID: 19142) ]---------------

---------------[ 12-Dec-2012 16:13:01 -0500 (PID: 19142) ]---------------
DEBUG [L0390] [14ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [95ms]:   <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [126ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [137ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [149ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [149ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [150ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
DEBUG [L0184] [150ms]:  <b>Debug::Text()</b>: Detected PHP errors (1), emailing log...<br>
DEBUG [L0184] [150ms]:  <b>Debug::Text()</b>: ---------------[ 12-Dec-2012 16:13:01 -0500 (PID: 19142) ]---------------<br>
---------------[ 12-Dec-2012 16:13:01 -0500 (PID: 19142) ]---------------

---------------[ 12-Dec-2012 16:14:01 -0500 (PID: 19159) ]---------------
DEBUG [L0390] [13ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [128ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [139ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [151ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [151ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [151ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
---------------[ 12-Dec-2012 16:14:01 -0500 (PID: 19159) ]---------------

---------------[ 12-Dec-2012 16:14:01 -0500 (PID: 19159) ]---------------
DEBUG [L0390] [13ms]:   <b>[Function]()</b>: Version: 5.1.0 Edition: 10 Production: 0 Demo Mode: 0<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: PHP ERROR - WARNING(2): date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you u<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: sed any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead File: /var/www/html/Ti<br>
DEBUG [L0117] [94ms]:   <b>Debug::ErrorHandler()</b>: meTrex_old/includes/Database.inc.php Line: 117<br>
DEBUG [L0167] [128ms]:  <b>TTDate::setTimeZone()</b>: Setting TimeZone: America/New_York<br>
DEBUG [L0542] [139ms]:  <b>Install::checkPHPVersion()</b>: Comparing with Version: 5.3.3<br>
DEBUG [L0438] [151ms]:  <b>TTi18n::chooseBestLocale()</b>: Choosing Best Locale...<br>
DEBUG [L0513] [151ms]:  <b>TTi18n::chooseBestLocale()</b>: Unable to find and set a locale.<br>
DEBUG [L0050] [151ms]:  <b>[Function]()</b>: CRON: Installer is enabled, skipping cron jobs for now...<br>
DEBUG [L0184] [154ms]:  <b>Debug::Text()</b>: Detected PHP errors (1), emailing log...<br>
DEBUG [L0184] [154ms]:  <b>Debug::Text()</b>: ---------------[ 12-Dec-2012 16:14:01 -0500 (PID: 19159) ]---------------<br>
---------------[ 12-Dec-2012 16:14:01 -0500 (PID: 19159) ]---------------
And in my apache error log I see:

Code: Select all

PHP Fatal error:  Uncaught exception 'ADODB_Exception' with message 'mysqli error: [1146: Table 'timetrex.company_generic_map_id_seq' doesn't exist] in adodb_throw(\n\nUPDATE company_generic_map_id_seq set ID = ( select max(id) from company_generic_map )+1, )\n' in /var/www/html/TimeTrex_old/classes/adodb/adodb-exceptions.inc.php:78\nStack trace:\n#0 /var/www/html/TimeTrex_old/classes/adodb/adodb.inc.php(227): adodb_throw('mysqli', 'adodb_throw', 1146, 'Table 'timetrex...', '??UPDATE compan...', false, Object(ADODB_mysqli))\n#1 /var/www/html/TimeTrex_old/classes/adodb/adodb.inc.php(1050): ADODB_TransMonitor('mysqli', 'EXECUTE', 1146, 'Table 'timetrex...', '??UPDATE compan...', false, Object(ADODB_mysqli))\n#2 /var/www/html/TimeTrex_old/classes/adodb/adodb.inc.php(1017): ADOConnection->_Execute('??UPDATE compan...', false)\n#3 /var/www/html/TimeTrex_old/classes/modules/install/InstallSchema_Base.class.php(125): ADOConnection->Execute('??UPDATE compan...')\n#4 /var/www/html/TimeTrex_old/classes/modules/install/InstallSchema_Base.class.ph in /var/www/html/TimeTrex_old/classes/adodb/adodb-exceptions.inc.php on line 78, referer: http://192.168.3.184/TimeTrex_old/interface/install/DatabaseSchema.php?external_installer=
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

So there is at least one unrelated issue that should be fixed, by adding the "system_timezone" setting to your timetrex.ini.php [other] section like this:

Code: Select all

[other]
system_timezone = EST5EDT
As for the SQL error, what version of TimeTrex are you trying to upgrade from?
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

I copied the data and database from my production server which runs 5.0.8 and mysql. The older database which I also tried using, from before my problems began, was a backup from when I was running (I think) 5.0.7.

The production server still seems to work fine after the database upgrade failed. I'm looking to migrate to postgres and to stay current with releases. As a last resort I can use a clean install of 5.1.0 on postgres, but that would mean manually defining employees, schedules etc.
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

You definitely should not be using v5.1.0 if the upgrade failed, thats a good way to lose/corrupt all your data. For now you will need to go back to v5.0.8.

We will be releasing v5.2.0 soon, you could give that a try to see if it works, if not we will need to diagnose it further.
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

The Help..About reports Version: 5.0.8. Does that make me safe, or should I try to actually install 5.0.8?
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

It does not, you need to make sure you aren't using any files from v5.1.0 at all.
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

Is there an easy way to tell?
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

Restore your database from its latest backup and install v5.0.8 over top of your existing installation. Unless you have a copy of the original v5.0.8 files of course, which would be even better.
Batrams
Posts: 45
Joined: Mon Aug 18, 2008 9:11 am

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by Batrams »

OK thanks I'll do that. In case the info is useful, I created the table which my apache error log said was missing and again tried to upgrade the database just for fun. This time it sill failed but the apache error logs changed and mentioned another missing table or two.

Do you think the next release really has a chance of working, or should I just go ahead and start with a fresh postgres install? I'm hoping to start using the new install of TimeTrex on 1/1/20013
shaunw
Posts: 7839
Joined: Tue Sep 19, 2006 2:22 pm

Re: Upgrading to 5.1.0 - database upgrade won't finish

Post by shaunw »

Its hard to say, the problem with MySQL is if there is any error whatsoever, your entire database is essentially corrupted and needs to be restored from backup. If this isn't done 100% of the time, everytime, its extremely hard to track down the root cause of the problem. It also makes it time consuming to run tests. In some cases the actual root cause of a problem happened 4 or 5 upgrades ago and is just now coming to light.

If you are willing to email (support@timetrex.com) a dump of your MySQL database (a working copy from your most recent backup) I can pass it on to our developers to investigate.
Locked