On the off-chance that this is of any use to anyone, I'd been receiving the exact same error message (as above) when attempting to update from Joomla 3.1.5 to 3.2.1. Though, in my case, I was not seeing any of the scary back-end lock outs.Lincky wrote:Hello,
I try to update my joomla in the backoffice, and i got this error:
1050 Table 'bamj_postinstall_messages' already exists SQL=CREATE TABLE `bamj_postinstall_messages` ( `postinstall_message_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `extension_id` bigint(20) NOT NULL DEFAULT '700' COMMENT 'FK to #__extensions', `title_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for the title', `description_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for description', `action_key` varchar(255) NOT NULL DEFAULT '', `language_extension` varchar(255) NOT NULL DEFAULT 'com_postinstall' COMMENT 'Extension holding lang keys', `language_client_id` tinyint(3) NOT NULL DEFAULT '1', `type` varchar(10) NOT NULL DEFAULT 'link' COMMENT 'Message type - message, link, action', `action_file` varchar(255) DEFAULT '' COMMENT 'RAD URI to the PHP file containing action method', `action` varchar(255) DEFAULT '' COMMENT 'Action method name or URL', `condition_file` varchar(255) DEFAULT NULL COMMENT 'RAD URI to file holding display condition method', `condition_method` varchar(255) DEFAULT NULL COMMENT 'Display condition method, must return boolean', `version_introduced` varchar(50) NOT NULL DEFAULT '3.2.0' COMMENT 'Version when this message was introduced', `enabled` tinyint(3) NOT NULL DEFAULT '1', PRIMARY KEY (`postinstall_message_id`) ) DEFAULT CHARSET=utf8;
When I then went to Extensions > Extension Manager > Database, I would see the following;
Clicking the 'Fix' button would resolve these messages and, to the best of my knowledge, everything was then working fine - though given the massive variety of bugs reported by others, I wasn't content to leave it at that. I wanted to know why the upgrade was kicking up errors in the first place.Warning: Database is not up to date!
Table 'jos_modules' does not have column 'asset_id'. (From file 3.2.0.sql.)
Table 'jos_users' does not have column 'otpKey'. (From file 3.2.0.sql.)
Table 'jos_users' does not have column 'otep'. (From file 3.2.0.sql.)
I found the answer to my problem. Here's what was happening;
- Like a responsible administrator, I was using a duplicate installation on which to test my upgrades. I was not upgrading my live installation.
- When I wanted to test something from scratch, I would use Akeeba Backup to take a fresh snapshot of my live site and restore that onto my test environment.
- Prior to restoring from a backup, I deleted all files from the test site's web directory - but I did NOT delete or erase the database. I simply overwrote the DB during the Akeeba Kickstart restoration. I had specified that Akeeba Kickstart should DROP existing tables during restoration ... and I'm not sure that it was. That, or there was a load of content that somehow didn't match up - because my database was 3 times the size it should have been.
This solution obviously won't be as simple for everyone - but it also struck me that other people might have (at some stage) performed a restore from a backup over the top of a populated database on a production environment - which could have contributed to some of the issues described above. It's also worth noting that this site was built upon Joomla 3.0.x initially, so I didn't ever have to upgrade from Joomla 2.x or 1.5 - which may or may not have left its own baggage behind.
I hope that's of some use to someone.