Thread

I was upgrading from 2.1.3 to 2.3.0, and then got the following error:

Error Number: 1091

Can’t DROP ‘site_id’; check that column/key exists

ALTER TABLE `exp_sessions` DROP `site_id`

Filename: updates/ud_230.php

Line Number: 68

I am now successfully running the site as 2.2.2, but would obviously like to complete the upgrade process and be onto 2.3.0 goodness.

Is it a bug or did I do something wrong?

Thanks
Terry

Hi, vibe9. I didn’t run into this going from 2.2.2 to 2.3.0. I spoke with one of my co-workers, and he didn’t run into it.. let me see if I can replicate.

Thanks Sue!
I can give you FTP and CP access if you want to check it out.

Let me see if I can first replicate it. Installing 2.1.3 now. 😊

OK, did a very vanilla upgrade from 2.1.3 to 2.3.0 - no issues here.

While I can’t replicate the problem, I can get you past the problem, there’s only one more change to make database wise.

Ok, please let me know what that change is 😊

Terry, could you check to see if the “site_id” column actually exists in your “exp_sessions” table?

I just ran into a related problem upgrading to 2.3.0. I carefully stepped through the whole upgrade process, though I was puzzled that, at the conclusion of running the upgrade script, I was prompted to run the upgrade script. It wouldn’t run again, though, so I deleted the upgrade folder. Then, though the admin section was fine, no public pages could load. I turned on full verbosity in “Output and Debugging Preferences,” and got this error:

A Database Error Occurred
Error Number: 1054

Unknown column 'site_id' in 'where clause'

SELECT `member_id`, `admin_sess`, `last_activity` FROM (`exp_sessions`) WHERE `session_id` = '62a37320bd7e0b80bd47c4510edfbd2d52cdda8a' AND `ip_address` = '137.54.140.169' AND `user_agent` = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1' AND `site_id` = 1

Filename: libraries/Session.php

Line Number: 708

I quickly altered exp_sessions and added a site_id column (making it of type “text,” figuring that’d cover everything), and the site worked immediately. (So, what should the data type be for that field?)

So, count this as another report of broken-ness pertaining to the site_id column in exp_sessions.

Hi Waldo,

It looks like you’re definitely not running EE 2.3 yet, as in that version, “site_id” is not a column in that table. EE isn’t looking for that column in that table.

The best way to handle this issue with your installation at this point is to roll your site back to its pre-upgrade state using the backups you took before performing the upgrade. Make sure to drop all tables from your database first so that you don’t end up with a corrupted database on your second go at the upgrade.

Now as you perform the upgrade again, if any problem arises, stop immediately and post back here with the error. We’ll jump in and help get you through it. If you don’t see an error this time, still post back here and let us know which version you ended up on. (And keep in mind that we just released 2.3.1, which includes a security update from 2.3.0.)

It looks like you’re definitely not running EE 2.3 yet, as in that version, “site_id” is not a column in that table.

If I’m not running EE 2.3, then why does the admin section inform me that I’m running “v2.3.0 - Build: date 20110801”? If that could be wrong, then what sort of authoritative source exists where I could determine what version that I’m actually running?

Rolling back the site would eliminate three days’ work by a trio of people, and taking the site down long enough to seek and receive help here could quite easily get me fired, so if I’m going to have to do either—or both—of these things, I need to make absolutely sure that they’re necessary.

Waldo Jaquith,

I looked at my test installation of 2.3.0, which was a clean install, and site_id in exp_sessions is type int(4).

What version were you upgrading from when you began? As for the version being reported in the Control Panel, ExpressionEngine writes the version number to /system/expressionengine/config/config.php at the end of each upd_xxx.php script to increment the version. That can cause the version to be technically out of sync in situations like this.

Honestly, the best plan forward is the advice Kevin outlined above. Roll back and run the update again to insure the most stable system and to avoid problems in the future.

Cheers,