OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums OroCRM Upgrade error – 1.5.0/1.7.0

This topic contains 20 replies, has 7 voices, and was last updated by ignat ignat 4 years, 10 months ago.

  • Creator
    Topic
  • #30113

    Rodolfo
    Participant

    Hi guys!

    I’m trying to upgrade (1.4.0/1.6.2) to (1.5.0/1.7.0). But I’m getting some errors:

    – Changed my composer.json to use platform/crm 1.5.0 and crm-enterprise 1.7.0
    – Ran composer.phar update –prefer-dist
    – Removed cache manually: rm -rf app/cache/*
    – Tried to update platform but nothing happens: php app/console oro:platform:update -e prod –force
    ** I got the white screen and no log files. When I ran using app_dev.php I got some errors and googled about the that. Changed my config.yml to use this:

    Tried again and finally I was able to update but I’m still having some errors:
    php app/console oro:platform:update –env=prod –force

    $ php app/console oro:platform:update –env=prod –force -vvv
    Process migrations…
    > OroCRM\Bundle\AccountBundle\Migrations\Schema\v1_6\CreateActivityAssociation
    ERROR: The table with name ‘oro_crm_ee_prod.oro_rel_46a29d19b28b6f386b70ee’ already exists.
    > OroCRM\Bundle\AccountBundle\Migrations\Schema\v1_7\OroCRMSalesBundle – skipped
    > OroCRM\Bundle\CallBundle\Migrations\Schema\v1_3\CreateActivityAssociation – skipped
    > OroCRM\Bundle\CallBundle\Migrations\Schema\v1_3\OroCRMCallBundle – skipped
    > OroCRM\Bundle\CallBundle\Migrations\Schema\v1_4\AddCreatedAtAndUpdatedAt – skipped
    > OroCRM\Bundle\CallBundle\Migrations\Schema\v1_4\OroCRMCallBundle – skipped
    > OroCRM\Bundle\ChannelBundle\Migrations\Schema\v1_3\OroCRMChannelBundle – skipped
    > OroCRM\Bundle\TaskBundle\Migrations\Schema\v1_2\CreateActivityAssociation – skipped
    > OroCRM\Bundle\TaskBundle\Migrations\Schema\v1_2\OroCRMTaskBundle – skipped
    > Oro\Bundle\CalendarBundle\Migrations\Schema\v1_3\OroCRMTaskBundle – skipped
    > Oro\Bundle\CalendarBundle\Migrations\Schema\v1_4\OroCRMTaskBundle – skipped
    > OroCRM\Bundle\AnalyticsBundle\Migrations\Schema\v1_0\OroCRMAnalyticsBundle – skipped
    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_13\OroCRMSalesBundle – skipped
    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_14\OroCRMSalesBundle – skipped
    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_15\OroCRMSalesBundle – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_23\OroCrmMagentoBundle – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_24\AddFields – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_24\OroCRMMagentoBundle – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_24\DropFields – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_25\ChangeAddressPostalCodeLength – skipped
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_25\AddRFMMetrics – skipped
    > OroPro\Bundle\OrganizationBundle\Migrations\Schema\v1_0\OroProOrganizationBundle – skipped
    > Oro\Bundle\MigrationBundle\Migration\UpdateBundleVersionMigration
    > Oro\Bundle\EntityExtendBundle\Migration\RefreshExtendCacheMigration – skipped
    > Oro\Bundle\EntityConfigBundle\Migration\UpdateEntityConfigMigration – skipped
    > Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendConfigMigration – skipped
    > Oro\Bundle\ActivityListBundle\Migration\ActivityListMigration – skipped
    > Oro\Bundle\EntityExtendBundle\Migration\UpdateExtendIndicesMigration – skipped

    [RuntimeException]
    Failed migrations: OroCRM\Bundle\AccountBundle\Migrations\Schema\v1_6\CreateActivityAssociation.

    oro:migration:load [–force] [–dry-run] [–show-queries] [–bundles[=”…”]] [–exclude[=”…”]] [–timeout[=”…”]] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    [RuntimeException]
    The command terminated with an exit code: 1.

    oro:platform:update [–force] [–timeout[=”…”]] [–symlink] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    Do you guys know how to solve this? Tried to rename that table but still got other errors.
    Thanks!

Viewing 5 replies - 16 through 20 (of 20 total)
  • Author
    Replies
  • #30129

    Rodolfo
    Participant

    Thank you for the answer @yshyshkin !

    Assuming that I want to upgrade my production environment, I’ll not use this option excluding this bundle. So, Anyone have other idea how to solve this problem in my Production Env?

    > OroCRM\Bundle\AccountBundle\Migrations\Schema\v1_6\CreateActivityAssociation
    ERROR: The table with name ‘oro_crm_ee_prod.oro_rel_46a29d19b28b6f386b70ee’ already exists.

    Thanks

    #30130
    ignat
    ignat
    Participant

    Hi guys,

    Looks as the problem is related to update to master instead of 1.6.2 EE that was causing the problem in http://oroinc.com/orocrm/forums/topic/someone-managed-to-upgrade-oro-to-1-6-1-or-1-6-2-without-any-errors. I guess that there are some elements in db schema and some data in db that was already pushed there. So update procedure is trying to apply changes that were already applied (http://oroinc.com/orocrm/forums/topic/someone-managed-to-upgrade-oro-to-1-6-1-or-1-6-2-without-any-errors/page/2/#post-7501).

    I think in this case the only option would be to figure out what SQL queries should be executed in the database of Rodolfo’s application to make update procedure pass. But it requires analysis and debugging based on current application’s dump. Of course data can be truncated in tables with confidential information like accounts/contacts/events etc.

    Rodolfo could you prepare such dump and someone available will try help you?

    Thanks,
    Ignat

    #30131

    Rodolfo
    Participant

    Any chances to help me without the full dump?

    #30132

    Rodolfo
    Participant

    I changed the version in oro_migrations table every time I got error. I’m going to test for some days in my Production/Clone server before upgrade my real prod server.

    Thank you guys!

    > OroCRM\Bundle\AccountBundle\Migrations\Schema\v1_6\CreateActivityAssociation
    ERROR: The table with name ‘oro_18.oro_rel_46a29d19b28b6f386b70ee’ already exists.

    > OroCRM\Bundle\CallBundle\Migrations\Schema\v1_3\CreateActivityAssociation
    ERROR: The table with name ‘oro_18.oro_rel_6cbc80002da17977bb66fd’ already exists.

    > OroCRM\Bundle\TaskBundle\Migrations\Schema\v1_2\CreateActivityAssociation
    ERROR: The table with name ‘oro_18.oro_rel_f24c741bb28b6f386b70ee’ already exists.

    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_13\OroCRMSalesBundle
    ERROR: The table with name ‘oro_18.oro_rel_6cbc800088a3cef5d4431f’ already exists.

    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_14\OroCRMSalesBundle
    ERROR: The table with name ‘oro_18.oro_rel_f24c741b88a3cef5d4431f’ already exists.

    > OroCRM\Bundle\SalesBundle\Migrations\Schema\v1_15\OroCRMSalesBundle
    ERROR: The table with name ‘oro_18.oro_rel_46a29d1988a3cef5d4431f’ already exists.

    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_23\OroCrmMagentoBundle
    ERROR: The table with name ‘oro_18.oro_rel_46a29d19784fec5f827dff’ already exists.

    #30133
    ignat
    ignat
    Participant

    Hi Rodolfo,

    Errors you are getting as I said before are result of sequence of actions: update to master, revert to original version but without reverting db and then update to new release version.

    You don’t need to provide full dump actually. What we need to help you is database schema in same state and some important data in system tables.

    So we will checkout 1.6.2 enterprise application, apply changes to schema to make it similar with yours, try to update to 1.7.0 and figure out how to fix this update.

    I can see two options to provide such dump:

    1. Make dump of DB of application that you are trying to update but before truncate confidential data like contacts, events, some users confidential data, etc. Though it’s important to keep data of system tables, like oro_entity_*, oro_config_*, oro_migrations_*.

    2. Provide SQL that will adjust state of orignal DB schema of application on version 1.6.2 to your actual state of DB. It will be like a diff between schema in your DB and schema in 1.6.2. Thus we will be able to prepare application on 1.6.2 version and apply this queries to have same schema’s state as in your application. Still data of tables oro_entity_*, oro_config_*, oro_migrations_* should be also provided.

    Thanks,
    Ignat

Viewing 5 replies - 16 through 20 (of 20 total)

You must be logged in to reply to this topic.

You will be redirected to [title]. Would you like to continue?

Yes No