Page 1 of 1

Upgrading to 5.1.0 - database upgrade won't finish

Posted: Tue Oct 30, 2012 2:32 pm
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

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

Posted: Tue Oct 30, 2012 3:43 pm
by shaunw

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

Posted: Wed Oct 31, 2012 4:53 pm
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).

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

Posted: Wed Dec 12, 2012 12:11 pm
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

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

Posted: Wed Dec 12, 2012 1:47 pm
by shaunw
We will need to see debug logs from TimeTrex during the install process.

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

Posted: Wed Dec 12, 2012 1:53 pm
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

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

Posted: Wed Dec 12, 2012 2:20 pm
by shaunw
Verbosity should be 10 rather then 11, otherwise the installer won't work.

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

Posted: Wed Dec 12, 2012 2:30 pm
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=

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

Posted: Wed Dec 12, 2012 2:55 pm
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?

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

Posted: Wed Dec 12, 2012 3:25 pm
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.

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

Posted: Wed Dec 12, 2012 4:33 pm
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.

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

Posted: Wed Dec 12, 2012 4:46 pm
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?

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

Posted: Wed Dec 12, 2012 5:51 pm
by shaunw
It does not, you need to make sure you aren't using any files from v5.1.0 at all.

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

Posted: Wed Dec 12, 2012 6:54 pm
by Batrams
Is there an easy way to tell?

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

Posted: Wed Dec 12, 2012 10:18 pm
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.

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

Posted: Thu Dec 13, 2012 5:03 am
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

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

Posted: Thu Dec 13, 2012 9:20 am
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.