Error in 1.7.5 to 2.0 upgrade

[zigojacko]

Changing the table prefix made no difference for me. I tried two different approaches - first I changed the table prefix before clicking upgrade, the second time, I waited until after the update had finished (with error message) then changed table prefix.

Any attempt resulted in the same error during update followed by the inability to run the complete_migration.php script and all pages if Feng install loaded blank white page (even with autoloader.php deleted).

I had only recently upgraded to 1.7.5 so there was nothing wrong with my install of FO at all.

[franponce87]

Hello everyone,

I made a mistake in my post in this thread, and I meant that the change from the og_ prefix to fo_ should be done before the upgrade (not after), I am sorry about it.

So, this is the whole process one should follow to migrate from Feng Office 1.7.5 to 2.0 (in case you have a previous version, it is better if you upgrade it to 1.7.5 first)

1- Back up all of your data (file system and data base) in case anything goes wrong
2- Create a new directory to keep all of the new files of the new version
3- Change the TABLE_PREFIX at the config/config.php from og_ (or whatever) to fo_ and also change the database data.
4- Delete the cache/autoloader.php file (it will be regenerated automatically later on)
5- Access your installation and go to /public/upgrade and run the upgrade
6- When the upgrade is over, click on the link that says 'Complete migration' or alike, and in case you missed it, run it from public/upgrade/complete_migration.php
7- Wait a while.. the migration takes long depending on your server/computer and the amount of data.
8- If you have a lot of data, repeat the steps 6 to 8 until you have the same amount of records in the fo_objects table as in the fo_processed_objects

We will be working on this last step to improve it, but for the time being it is the only way

Please post your new feedback here, whether it is a good one or a bad one, so in case something went wrong someone else might come with the solution.

Sorry for those who got it wrong.

Best regards,
Francisco

[winhex]

franponce87 , Thank you for your recipe, updating was successful. But when I opened FO - it did not have any tasks, no notes, nothing. Sorry, but the update does not work correctly 

[freeraider]

I DID IT!

If you have this error in log.php

ERROR: Error: gzuncompress(): data error in '/var/www/html/fengoffice/application/functions.php' on line 1377 (error code: 2)


comment this lines in config.php before upgrading

  //DEFINE ( 'COMPRESSED_CSS', True);
  //DEFINE ( 'COMPRESSED_JS', True);
  //DEFINE ( 'USE_JS_CACHE', True);

[freeraider]

I have this error
DEBUG: SQL ERROR: Query failed with message 'Table 'fo2.fo_custom_properties_by_co_type' doesn't exist' - SELECT `cp_id` FROM `fo_custom_properties_by_co_type` WHERE `co_type_id` = 3

I copy table og_custom_properties_by_co_type to fo_custom_properties_by_co_type by phpMyAdmin

[freeraider]

I have lost Custom Properties after upgrading

How can I get it back?

[franponce87]

I have added an 8th step in the procedure, please look into it and try again as it is very important as well.

Best regards,
Francisco

[winhex]

franponce87 , after runing 8th step I saw my tasks  in the Overview tab, but when I open them a message appears:

We are sorry, but Feng Office is not currently able to execute your request. An Error Report has been sent to the administrator.

But all the documents and notes are available and open well

[franponce87]

Are you sure you have ran the process as many times as needed?
If so, you should look into the log.php file for further information, that way you may be able to figure out what else is missing or what went wrong.

Best regards,
Francisco

[ritmo]

.....

3- Change the TABLE_PREFIX at the config/config.php from og_ (or whatever) to fo_ and also change the database data.
.....

Thanks for the clarification, but what do you mean by "..and also change the database data"? If an update to FO 2.0 is being done in situ, what data is there that should be changed?

Please explain.

Thanks,
David

[PetterSandvik]

This is ment like database login, prefix etc - not "data" actually.

[PetterSandvik]

After upgrade no more data than settings/contacts/workspcaes was added. The emails etc is COPIED to the new database tables - but it dont show up in Feng! What is that error? It like im missing some rights or something.

EDIT: Now i found solution! I needed to go to the access settings to my user and select full rights to each workspace - then i see all emails etc.

Trought - new emails etc is showing up.

So there is a bug that makes rights to old objects falling away - so people with big insatllations or that need exact rights wait to this is fixed.

[ritmo]

Thought I would contribute something to assist those of us that have wasted a collective hundreds of hours in coming to grips with this migration challenge.

Attached is a Process Map of the steps as currently recommended, as well as the optional steps I took in trying to make sense of it all. I assume a v1.7.5 installation as a starting point, as is the case with probably most of us here.

Below are the two alternative approaches presented:

1. Begin at Start 1:
As I did, in order to eliminate all risk of messing up the main site, you start with a Test Bed v1.7.5 installation created in a separate folder on the same domain as the main installation (also v1.7.5).
For this approach, follow steps 1 through 10 of the attached process map.

2. Begin at Start 2:
If you simply wish to upgrade your current v1.7.5 installation directly, follow Steps 5a through 10a of the process map.

If nothing else, the ability to refer to the process map makes any related discussion a little easier.

Cautionary Notes
Even after getting v2.0.0.8 to the point where I could login and potentially see all my data, there are still some unanswered questions, such as:

a) Why are there still og_ table entries in the database?
b) With the persistent og_ entries, the total number of tables is now more than double that of the original installation!
c) The database table entries for fo_objects and fo_processed_objects still differ by 1.
d) Given the above, how can I be sure of the data that will be presented to the user?

My final comment is that there are obviously too many 'moving parts' in this overall migration process to make it what I would call robust. Without the help of a migration script that includes ALL necessary error checking, etc., it takes only a single, simple mistake and the whole thing fails in a hurry.

I think skyer2000 is on the mark with his comment - the current script certainly needs more work!


I hope this helps at least some of you who have no particular expertise in this subject, but appreciate the value of Feng Office. Please let me know if there are any recommended changes, and I will update the document as required.

Cheers,
David

[dansmith65]

Thanks to the new info by franponce87, I had better luck with the upgrade this time. I am still experiencing a lot of issues with my upgraded system though, but i'll be reporting most of them to fengoffice.com/bugs.

One issue I wanted to mention here is that the final step to completing the upgrade process is not very clear. I've attached a screenshot (redundant, I suppose since it's also in ritmo's pdf).

[hubschraubaer]

Dear all,

I followed the steps recommended by Francisco to upgrade from 1.75 to 2.0 so far but there is an issue with the complete_migration.php script (see full log below). I crawled through the DB upgrade scripts and templates as well as the original "vanilla" DB schema in the install folder of 2.0 but cannot find a designated 'id' field in the fo_timeslots table.

The 'Unknown column 'id' in 'field list'' error seems to prevent the complete migration of my data. The "fo_processed_objects" table is empty and I cannot see any tasks in the workspaces task list (We are sorry, but Feng Office is not currently able to execute your request. An Error Report has been sent to the administrator.).

Apart from that the tasks are shown in the Overview tab as also mentioned by winhex above.

Any ideas how to fix that?

Kind regards,
Dirk

-----------------------------------
Session "default" started at 2012-04-22T10:04:17+0000                                                                                                                                           
#1 DEBUG: SQL ERROR: Query failed with message 'Unknown column 'id' in 'field list'' - SELECT `id`, `object_id`, `object_manager`, `start_time`, `end_time`, `user_id`, `description`, `created_o
n`, `created_by_id`, `updated_on`, `updated_by_id`, `paused_on`, `subtract`, `fixed_billing`, `hourly_billing`, `is_fixed_billing`, `billing_id` FROM `fo_timeslots` WHERE `id` = '72'           
#2 FATAL: exception 'DBQueryError' with message 'Query failed with message 'Unknown column 'id' in 'field list''' in /srv/www/clients/client1/web1/web/office/environment/library/database/adapte
rs/AbstractDBAdapter.class.php:386                                                                                                                                                               
    Stack trace:                                                                                                                                                                                 
    #0 /srv/www/clients/client1/web1/web/office/environment/library/database/adapters/AbstractDBAdapter.class.php(285): AbstractDBAdapter->prepareAndExecute('SELECT `id`, `o...', NULL)         
    #1 /srv/www/clients/client1/web1/web/office/environment/library/database/DB.class.php(179): AbstractDBAdapter->executeOne('SELECT `id`, `o...', NULL)                                       
    #2 /srv/www/clients/client1/web1/web/office/environment/classes/dataaccess/DataManager.class.php(477): DB::executeOne('SELECT `id`, `o...')                                                 
    #3 /srv/www/clients/client1/web1/web/office/environment/classes/dataaccess/DataManager.class.php(442): DataManager->loadRow(72)                                                             
    #4 /srv/www/clients/client1/web1/web/office/environment/classes/dataaccess/DataManager.class.php(346): DataManager->load(72, false)                                                         
    #5 /srv/www/clients/client1/web1/web/office/application/models/timeslot/base/BaseTimeslots.class.php(171): DataManager->findById(72, false)                                                 
    #6 /srv/www/clients/client1/web1/web/office/application/models/timeslot/base/BaseTimeslots.class.php(173): BaseTimeslots->findById(72, false)                                               
    #7 /srv/www/clients/client1/web1/web/office/application/models/objects/Objects.class.php(17) : eval()'d code(1): BaseTimeslots::findById(72)                                                 
    #8 /srv/www/clients/client1/web1/web/office/application/models/objects/Objects.class.php(17): eval()                                                                                         
    #9 /srv/www/clients/client1/web1/web/office/public/upgrade/complete_migration.php(53): Objects::findObject('72')                                                                             
    #10 {main}