2

We currently are working on 2 Magento sites, one is Enterprise 1.11 and one is Enterprise 1.13, if we take too long testing out all out modifications in 1.13 then we plan on getting a security patch for 1.11 and use that as the production site, otherwise we will use 1.13

natully, bugs found in 1.11 still need to be fixed and we are also being told to make other modifications to 1.11 despite the fact we are trying to get 1.13 working, some fixes/mods for 1.11 involve database edits

now i though if i restored my database to the latest dumped version of 1.11 we have and run a 1.13 version of magento the database would update itself, however it's not, firstly, when i go into a category after landing on the home page i get this exception error

Unknown column 'rule.calculate_subtotal' in 'field list'

looking over the update .php files and there is a upgrade-1.6.0.3-1.6.0.4.php in /app/code/core/Mage/Tax/sql/tax_setup/, looking in core_resource in both the 1.11 database i'm trying to upgrade and 1.13 database that i have been working on for a while (which is fully upgraded but doesn't have most of the database edits) and the 1.13 database shows both version and data_version for tax_setup to be 1.6.0.4, in the 1.11 database they both show 1.6.0.3 (one at least should be 1.6.0.4)

now if it was just edits to our custom tables we have added then there would be no problem but there are some banner/cms/system settings that have been chnaged and the sql dump file is almost 1GB so try doing a compare with that

i am wondering why Magento is not updating the database when it should, is there a cache i have to remove that isn't the var/cache or var/full_page_cache which i delete anyway

  • Had similar problems trying to upgrade 1.10 and 1.12 to 1.13. Both had third party modules that could have been the source of conflicts, but it seemed unlikely that they were. In all cases thus far, we've opted to just start with a fresh 1.13 database and import everything we can back in. Debugging the upgrades were just taking us too long to be worth it. – Sam Aug 7 '13 at 15:18
3

I don't have an Enterprise version of Magento to use at the moment, but regarding

the sql dump file is almost 1GB so try doing a compare with that

The mysqldump command's -d flag

mysqldump -d

can be used to avoid dumping the data from a database. In other words, it will only dump the structure. Additionally, mysqldump supports dumping specific tables — with some trial and error you could probably exclude the many large tables (mostly logs) if you needed to diff actual data.

  • thanks for your help, doing a dump of just the tables allowed me to work out what was going on, the database was a 1.13 database and it had a table that was created for 1.13, when i got an up to date version of the 1.11 database we're using and used that the 1.13 tables wasn't removed and there was an sql error being cause because a table already existed, the 1.11 dump only removed the tables it would create so i just needed to whip up a script to drop all tables without dropping the database (because i have 100+ procedures) and then import 1.11, upgraded fine – Memor-X Aug 12 '13 at 1:10
2

Firstly, if you are running an upgrade and it stops and you can not restart and then you go and restore again, you need to make sure you dump your old version of the database before you restore the version to upgrade.

Secondly, although Magento does not explicitly say this, I would recommend trying to upgrade to 1.12 first, then to 1.13.

http://www.magentocommerce.com/knowledge-base/entry/ee11302-ce18-install-upgrade#upgrade-ce18

We have successfully upgraded 5 EE1.13.0.2 sites (One from CE1.7 but none from 1.11)

I would also make sure you reindex after the upgrade using the command line.

Have you also run the shell/url_migration_to_1_13.php script?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.