6

I've just run through the upgrade process from EE 2.5.3 to 2.5.5 but when attempting to visit the control panel the following error is returned:

A Database Error Occurred Error Number: 1054

Unknown column 'session_id' in 'field list'

INSERT INTO exp_security_hashes (date, hash, session_id) VALUES (1358339646,'ab16daea8d642ede81116584166172107d5c30f1','3f3730359d532958f37f4de75c74e92c9747b441')

Filename: core/EE_Security.php

Line Number: 118

Has anyone else run into this problem?

Improve this question
1
  • Yes! Just had it.
    – foamcow
    Commented Jan 16, 2013 at 18:40

2 Answers 2

Reset to default
6

The installer/update script doesn't create the missing column. You can create it manually if you're comfortable editing your database. I was updating from 2.4 to 2.5.5 and ran into the same issue.

As with anything you should back up your database BEFORE doing the update or this procedure.

Run the following SQL on your database;

ALTER TABLE  `exp_security_hashes` ADD  `session_id` VARCHAR( 40 ) NOT NULL DEFAULT  '0' AFTER  `date`

This will create the necessary column. You can then run the admin.php script and all should be well. I've just done it and everything came back to normal.

I'm not sure why this isn't automatically created. I haven't yet looked at the update script itself to see if it's missing or just failing for some reason.

UPDATE: There is a function in one of the update files (ud_254.php) that changes the column ip_address to session_id. Whether that fails to execute because of permissions, a bug, or if the session_id column is used before is updated I do not yet know.

Improve this answer
5
  • I'd be reluctant to manually add the missing column as the installer should do that automatically. It could be worth double checking permissions and running again.
    – Ian Young
    Commented Jan 17, 2013 at 13:38
  • 4
    I managed to recreate the issue again and this time I narrowed it down to my config.php file. If your 'app_version' isn't set correctly before you run the installer it seems that the SQL queries run on update differ. I was updating from 252 to 255 so I needed to make sure this was set correctly: $config['app_version'] = "252"; This then changes to 255 when the installer has run successfully and doesn't show any DB errors. That may help to check.
    – Ian Young
    Commented Jan 22, 2013 at 17:41
  • That would make the whole file permissions thing a plausible reason. If the config file isn't writeable that could be it.
    – foamcow
    Commented Jan 25, 2013 at 16:19
  • I think so. I also tested when that variable wasn't set at all (commented out) and with an incorrect version and each time it causes the issue. It's worth checking it's both writable and correct on update.
    – Ian Young
    Commented Jan 25, 2013 at 19:57
  • Thank you, sir. Your answer saved my day too! expressionengine.stackexchange.com/q/18400/1615
    – Hansl
    Commented Jan 15, 2014 at 14:14
3

It looks like the installer didn't run properly and I suspect was a permissions issue. I set the appropriate permissions and then re-ran the installer and this time it seemed to run successfully and I could log back in to the control panel.

Improve this answer
5
  • Perfect! Please make sure to select your answer as correct by clicking on the checkmark to the left.
    – Anna_MediaGirl ♦
    Commented Jan 16, 2013 at 19:25
  • Permissions on what? Can you expand your answer for future reference?
    – foamcow
    Commented Jan 16, 2013 at 19:47
  • In my case I was upgrading locally on a Mac using MAMP Pro. I copied over the new directories and files but their r/w/x permissions weren't adjusted and the host was running under a different user without the correct permissions. I set those new directories and files (from the update) to allow for read and write for that user and then ran the installer again. This time it went through correctly. If I were on my web servers I'd have just used chmod to change these. Hope that helps.
    – Ian Young
    Commented Jan 17, 2013 at 13:36
  • Hmm I'm not sure how file permissions could affect creating a column in a database table though. Unless the file that contained the script didn't have execute permissions - but if that were the case how come everything else worked? I think I'll look into this more closely.
    – foamcow
    Commented Jan 17, 2013 at 16:45
  • Yeah in my case I think it was literally a case that the user the host was running under didn't have permissions to execute the script. I set those permissions and it ran successfully. I haven't looked in any detail as to what migrations etc the installer runs but I'd be very surprised if it didn't run the appropriate database migrations for you. If you create it yourself you'll be risking get the DB structure out of sync. I'd use that approach as a last resort.
    – Ian Young
    Commented Jan 17, 2013 at 18:58

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.