Ok, so let me explain the complete story: I have a VPS with a magento webshop installed, the Magento shop is being maintained by Installatron, as Installatron makes backups and does the updates when needed.

I was on 1.9.01 before and updated to without problems, but because we had some issue's with the skin (allready present in 1.9.01) which we tried fixing after the update somehow the whole webshot crashed.

So i placed back the backup of

Website working as before, but now i cannot update anymore, the update completes, in installatron is says but the website shows the error mentioned in the title:

There has been an error processing your request Exception printing is disabled by default for security reasons.

Error log record number: 1198252680343

The error log number changes, when trying to enter admin-url for example. I've have a copy of the logs here: https://dl.dropboxusercontent.com/u/32681465/error%20logs.zip

I've checked them and seems to be a mail issue? Not sure though, but think it's a MYSQL problem.

Hope someone can help me.

  • Just tried this with no result: stackoverflow.com/questions/15473705/… Commented Apr 24, 2015 at 17:47
  • I've changed the ''tmp'' back to ''null'' Commented Apr 24, 2015 at 17:47
  • According to your error log before restoring magento try to drop table mage_core_email_queue and open your site. It looks like some error appeared during upgrade process and magento think that it didn't finish.
    – zhartaunik
    Commented Apr 24, 2015 at 18:54
  • @zhartaunik Has a point, though that may just be the first exception being thrown and since it can't get past that one, there may be others waiting to be thrown after it. I'm not sure I would advocate running through your DB and dropping tables as you go, though it may work. Might be safer to restore to a previously known good state...just my 2 cents... Commented Apr 24, 2015 at 19:54
  • If i decide to do this: According to your error log before restoring magento try to drop table mage_core_email_queue and open your site. It looks like some error appeared during upgrade process and magento think that it didn't finish. – Commented Apr 24, 2015 at 20:43

1 Answer 1


During the Magento Upgrade process, it will attempt to update your Database schema to make changes to the way the Tables, Indices, Constraints and (with the latest updates) Triggers are configured and defined in your Database.

The log files you provided are indicating that one of the changes Magento is attempting to execute against your (I'm assuming MySQL) database is failing:

a:5:{i:0;s:1082:"Error in file: "/home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/sql/core_setup/upgrade-" - SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'mage_core_email_queue' already exists, query was: CREATE TABLE `mage_core_email_queue` (
  `message_id` int UNSIGNED NOT NULL auto_increment COMMENT 'Message Id' ,
  `entity_id` int UNSIGNED NULL COMMENT 'Entity ID' ,
  `entity_type` varchar(128) NULL COMMENT 'Entity Type' ,
  `event_type` varchar(128) NULL COMMENT 'Event Type' ,
  `message_body_hash` varchar(64) NOT NULL COMMENT 'Message Body Hash' ,
  `message_body` mediumtext NOT NULL COMMENT 'Message Body' ,
  `message_parameters` text NOT NULL COMMENT 'Message Parameters' ,
  `created_at` timestamp NULL default NULL COMMENT 'Creation Time' ,
  `processed_at` timestamp NULL default NULL COMMENT 'Finish Time' ,
  PRIMARY KEY (`message_id`),
  INDEX `747D3AF379628D00D009E037E2942C80` (`entity_id`, `entity_type`, `event_type`, `message_body_hash`)
) COMMENT='Email Queue' ENGINE=INNODB charset=utf8 COLLATE=utf8_general_ci";i:1;s:1154:"#0 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(437): Mage_Core_Model_Resource_Setup->_modifyResourceDb('upgrade', '', '')
#2 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(320): Mage_Core_Model_Resource_Setup->_upgradeResourceDb('', '')
#3 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/Resource/Setup.php(235): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/App.php(417): Mage_Core_Model_Resource_Setup::applyAllUpdates()
#5 /home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#6 /home/dynamodz/domains/dynamodz.com/public_html/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#7 /home/dynamodz/domains/dynamodz.com/public_html/index.php(87): Mage::run('', 'store')
#8 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

The code in the upgrade script "/home/dynamodz/domains/dynamodz.com/public_html/app/code/core/Mage/Core/sql/core_setup/upgrade-" is attempting to add a new table to your database, but MySQL is complaining with an error because that table already exists.

The problem with your previous attempt to "restore the backup" may have been that you only restored the Magento installation files and not a backup of your database. The first time a Magento site is accessed via URL, it's autoloader system runs through it's Core installation / upgrade scripts and those of all installed plugins and attempts to execute any DB setup scripts it finds that haven't been completed.

Whenever you install or create any new module that contains database interaction, you will find an install and upgrade script in that module’s code directory that will run once you hit the URL. Magento’s core modules also follow the same install and upgrade structure. If you want to see some examples, open app/code/core/Mage/Catalog/sql/ catalog_setup. Here, you will find several install and upgrade scripts with proper naming conventions along with their version numbers.

I would engage Installatron and request that they perform a restore of the database backup taken BEFORE you attempted the upgrade then restore your Magento files to the filesystem. That will get your system to a point where the database schema is consistent with the codebase in your Magento installation (hopefully, it's possible there were previous failed installations / upgrades that you're not aware of...)

Then, read this guide carefully and perform the upgrade steps documented there in the order listed. One thing you nee to be aware of is if your site is seeing traffic, the first user who hits the URL will cause Magento to execute the upgrade / installation, and subsequent visitors could trigger additional executions of those scripts (that's why the guide suggests performing it on a local machine or another computer that only you will be accessing).

If you can't do this, You can also

  1. Turn off your webserver (I'm assuming it's apache on a linux varient) : sudo httpd service stop
  2. ssh into your server
  3. navigate to your magento installation root directory
  4. Load your index.php via command-line php : php -f index.php
  5. Turn on your webserver : sudo httpd service start

You may not see any output to your screen, but when you get a command prompt back your installation scripts will have run and any errors will be logged in either the report section where you found your log files or in the var/log/system.log or var/log/exception.log files if you followed the instructions in the upgrade guide and have exception logging enabled.

  • Thanx for the detailed answer, the website with the update problems is on a other VPS, a old version is running live now on at a other hoster. About the update, what u say, i think this is true yes, as i can see in backend of installatron what has been backed up, and not all tables and files have been checked. I did not know why and as these were standard settings i never touched them. I backup runs perfect until i update. So the problem must be in 1 of the tables that is not being backed up. Commented Apr 24, 2015 at 20:31
  • Yeah it probably is, though depending on which tables they are the impact may be large or small. All of the tables in your schema SHOULD be backed up at the same time preferably in a TRANSACTION so that the backup captures the entire state of your database at a single moment in time. I'm sorry to say that if it isn't / hasn't then no matter what you do you're going to wind up with inconsistent data and potentially foreign keys referencing data in tables that doesn't exist. You can try running the magentocommerce.com/wiki/1_-_installation_and_configuration/… Commented Apr 24, 2015 at 20:37
  • That tool will at least make sure you have all the tables required, though it doesn't necessarily fix the situation where there are ROWS in the TABLES that reference other ROWS in other TABLES that don't exist (this is what a Foreign Key violation represents : en.wikipedia.org/wiki/Foreign_key) Commented Apr 24, 2015 at 20:39
  • I see, But: If i can make everything original or how it should be on (with the backup restored), perhaps then the update will work again. Removing the tables which are new in Is this a solution? Problem is, i dont have a complete backup of the complete hosting, as time past this has been overwritten, and i did not see this problem coming. Commented Apr 24, 2015 at 20:40
  • It's worth a try, can't be any worse than the current situation. As @zhartaunik noted, you should be ready to start working through the issues that you see one at a time and accept that you'll have to resolve them to get it fully functional and able to have any other updates installed. It's possible. You may wind up having to delete some data (customers or orders or other data) to have a functioning system, but that's better than no system at all. Commented Apr 24, 2015 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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