OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums 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 5 years, 6 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
  • #30113


    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

    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

    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.

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


    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.



    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?




    Any chances to help me without the full dump?



    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.


    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.


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

The forum ‘OroCRM’ is closed to new topics and replies.

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

Yes No