10 August 2010, 6:26

I'm trying to upgrade to 1.25 and I have a problem with the upgrade script:

'Could not execute command: ALTER TABLE "artefact_blog_blogpost_file" RENAME TO "artefact_attachment"'

But the table is renamed!?

I'm usiung a db prefix. Is this a problem?

What else?
thx,
Thomas

10 August 2010, 16:45

Thomas,

If you are using mysql, it's possible that the table was renamed during an earlier attempt at running the upgrade.

If you restore the db back to the one you were using with 1.1.6 does it have the table already renamed to artefact_attachment?

R.

11 August 2010, 3:07

Yes, I'm using mysql.
hm...

I've restored the db-dump and there is no table named attachment. After restoring I made a new directory on the server and put there all the files from mahara-1.2.5.zip. I also copied the config file from the 1.1.6.
- I opend the site and mahara tells me about the mime_magic error ([ENV] 12 Your server does not have the mime_magic extension enabled. Mahara may have trouble detecting file types.). Ok, I'll solve it later.
- I click on the "Perform the upgrade now" link:
-- [ENV] 7c Your server does not have the mime_magic extension enabled...
-- You are not using a UTF-8 database. Mahara stores all data as UTF-8 internally...
-- Performing upgrades:
--- Component: core
--- From Version 1.1.6
--- To version 1.2.5
--- Information: Could not execute command: ALTER TABLE "artefact_attachment" DROP FOREIGN KEY "arteblogblogfile_blo_fk"

hm, that's new...
What can i do?
thx

Screenshot

11 August 2010, 16:53

There will be some reason why mysql cannot run

ALTER TABLE "artefact_attachment" DROP FOREIGN KEY "arteblogblogfile_blo_fk"

and I guess we need to find out what that is.  There should be more information (perhaps an error code) in your webserver's error log.

Alternatively you could also try pasting that command into the mysql client and see what it tells you.

12 August 2010, 8:32

I didn't found it in error log.

I've pasted it in PhpMyAdmin and it says:

#1025 - Error on rename of '...artefact_attachment' to '..#sql2-1006-431fe6' (errno: 152)

Is this something you can work with?

16 August 2010, 2:56

Any Idea?
What shall I do?

16 August 2010, 17:05

Well, I'm almost out of ideas.  The first time you run the upgrade, it successfully renames the table, but then fails to drop the foreign key (for some reason).  When you run it a second time, it tries to rename the table and fails because it was already renamed the first time.

What happens if (before the first attempt) you do a "SHOW CREATE TABLE artefact_blog_blogpost_file"?  That should at least show you if you have a foreign key with the name "arteblogblogfile_blo_fk".

17 August 2010, 4:46

Thanks for this hint.

The answer from PhpMyAdmin is:

CREATE TABLE `artefact_blog_blogpost_file` ( 
  `blogpost` bigint(10) NOT NULL, 
  `file` bigint(10) NOT NULL, 
  PRIMARY KEY  (`blogpost`,`file`), 
  KEY `arteblogblogfile_ix` (`blogpost`), 
  KEY `arteblogblogfil2_ix` (`file`), 
  CONSTRAINT `arteblogblogfil2_fk` FOREIGN KEY (`file`) REFERENCES `artefact` (`id`), 
  CONSTRAINT `arteblogblogfile_fk` FOREIGN KEY (`blogpost`) REFERENCES `artefact` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

There is no key with the name "arteblogblogfile_blo_fk" :-(

17 August 2010, 20:16

I'm not sure why you have names on those constraints that are different to what the upgrade is expecting, but I don't think everyone else had this problem when upgrading, so maybe you could try renaming them all manually to the expected names before running the upgrade:

'arteblogblogfile_fk' => 'arteblogblogfile_blo_fk'

'arteblogblogfil2_fk' => 'arteblogblogfile_fil_fk'

'arteblogblogfile_ix' => 'arteblogblogfile_blo_ix'

'arteblogblogfil2_ix' => 'arteblogblogfile_fil_ix'

18 August 2010, 3:01

Yeah - thanks for your work

I didn't know if I can rename them manually.
Same problem in "artefact_blog_blogpost_file". I've renamed it too and now it works!
Upgrade completed

Thank you for your patience

Now I will try to solve the problem with the language pack...