I am getting three SQL errors when I attempt to upgrade from 1.5.2 to 1.6.3 No matter what I do, even if I delete tables and follow what SQL tells me, I can’t get out of them. Please see the errors below. Any ideas?

Description: Table ‘exp_sites’ already exists

Query: CREATE TABLE `exp_sites` ( `site_id` int(5) unsigned NOT NULL auto_increment, `site_label` varchar(100) NOT NULL default ‘’, `site_name` varchar(50) NOT NULL default ‘’, `site_description` text NOT NULL, `site_system_preferences` TEXT NOT NULL , `site_mailinglist_preferences` TEXT NOT NULL , `site_member_preferences` TEXT NOT NULL , `site_template_preferences` TEXT NOT NULL , `site_weblog_preferences` TEXT NOT NULL , PRIMARY KEY (`site_id`), KEY `site_name` (`site_name`))

Description: Can’t DROP ‘PRIMARY’; check that column/key exists

Query: ALTER TABLE `exp_member_groups` DROP PRIMARY KEY

Description: Duplicate column name ‘site_id’

Query: ALTER TABLE `exp_categories` ADD `site_id` INT(4) UNSIGNED NOT NULL DEFAULT 1 AFTER `cat_id`

MySQL ERROR:
Error Number: 1060

Description: Duplicate column name ‘site_id’

Query: ALTER TABLE `exp_category_groups` ADD `site_id` INT(4) UNSIGNED NOT NULL DEFAULT 1 AFTER `group_id`

MySQL ERROR:
Error Number: 1060

Description: Duplicate column name ‘site_id’

Query: ALTER TABLE `exp_comments` ADD `site_id` INT(4) UNSIGNED NOT NULL DEFAULT 1 AFTER `comment_id`

It looks like it’s trying to run an upgrade that it’s already run.  Does this happen on the very first upgrade link?  Going from 1.5.2->1.6.0?  Looks to me like that’s the case- which would suggest the config.php was not writable, so the version number didn’t get changed.  But the db changes DID happen- hence the errors.

Hm- check your exp_galleries table- does it have a field called ‘gallery_cf_six_searchable’?  If so, that’s the last of the db changes.  In which case, go in, change the version in the config manually to 160, make sure it’s writable, and go back to the main update page.  See if it allows you to go from 1.6.0->1.6.1.

That all make sense?

Hi Robin,

This is what I thought. The db changes apparently do go through, but are not being recognized. The config.php file appears to have 644 permissions. Do I need to give it 777?

Thanks,

Adrian

Typically 666.  Also- you’ll need to manually edit it so it syncs up to the database.  Right now, config is 1 version behind.  So- change

So it equals 160.

And a whole lot of info got pulled out of the config in the 1.6.0 update- so you might want to go back later and remove things.  But we can worry about that later- it’s really only an issue with MSM.  So let’s try to get the update complete before worrying.  There’s a copy in the wiki you can use when it comes time to tweak.

Make sense?

Sorry for the delay in posting a reply.
It still doesn’t work. I have done everything you have suggested, but I still get the db errors. The database gets indeed updated, but update.php keeps looping through errors. What should I do?

Thanks,

Adrian

Hm- ok- take a look at the exp_sites table in phpmyadmin- does it have content?  If so- and you manually edit your config.php so it shows

Does the update page come up and ask if you want to upgrade from 1.6.0->1.6.1?  And if so- what happens when you click the link?

Yes, this is what I have done step by step:

1. Ran the upgrade using the instructions posted on your site
2. Ran into trouble
3. Restored the original database
4. Updated the congif file to 160
5. Ran the upgrade again
6. Ran into trouble again

For what I can tell the database upgrade goes through completion, but the application can’t recognize it.

Thanks,

Adrian

It sounds like EE is unable to write to the config.php file.  We need to take it in little tiny steps.

What happend after you restored the original db?  Did you also restore the old config.php- you should have.  If the db was 1.5.2- should have the config for 1.5.2.  Then- click the first link- it shouldn’t have errored and you should then see a link to update 1.6.0->1.6.1.

At that point- stop, manually check the config.php- it should show the app_version being 160.

Is that what happened?  And if you need to redo again- stop at that point- don’t click past the first update- and let me know whether there were any errors and whether the config.php is now showing 160 as the version.

That make sense?

Hi Robin,

Sorry for the late reply. The db gets udpated, but config.php doesn’t get updated even though the permission is set to 666. What should I do?

Thanks,

Adrian

OK- so you went from 1.5.2->1.6.0.  You think the db changes occurred.  To check that- does exp_sites table exist?  Then go check exp_email_cache table- is there a field called ‘plaintext_alt’?  Check for those bits in the db- using phpmyadmin or something similar.

If they are there- go ahead and manually change the version number to 160.  Go to update again- should give you a link to update 1.6.0->1.6.1.  Click it- then grab the config again- does the version stilll show 160 or is it 161?

Hope I picked it up at the correct spot in the process.

Once we get this cleared out- I’d suggest asking the host what the permissions need to be in order for EE to write to that file.  But- let’s see if we can get you up on a solid version of 1.6.4 first.

Yes, the db gets updated, but the config file doesn’t get written even though the permissions are set properly. It occurs to me that perhaps we are facing a problem with the permission ownership rather than with permissions themselves. Who executes the permissions when the update runs? Apache? or some other user?

Thanks,

Adrian

That will vary from server to server, Adrian.  Since you seem to have a hang of restoring the old and trying over from scratch, go ahead and do that again, please, but this time first open update.php and at the very top find:

Just below that, add the following so we can make sure error reporting is enabled (if the server allows it):

Then on line 715, remove the @ symbol from in front of the fopen function, i.e.:

As well as on line 768:

Now when you run the update and it tries to write to the file, you should get an error indicating precisely why it cannot write to the file.

Ok, I have more to report on this.

I just noticed that the db changes took effect but there’s no field called plaintext_alt on exp_email_cache table. Everything else is in there.
I altered update.php to report erroors but got no errors reported. What should we do next?

Thanks,

Adrian

What do you mean exactly by “everything else is in there”?  What version did you end up on, and how did you confirm the fields?  It doesn’t seem plausible that you’d have ‘show_pages_cluster’ in exp_weblogs for instance, but not the ‘plaintext_alt’ column in exp_email_cache.  Is this installation self hosted or in a professionally managed environment?

All the other tables are there. plaintext_alt on exp_email_cache is the only field I don’t see listed using phpMyAdmin. I’m trying to go from 1.5.2 to 1.6.3, but no matter what I do the config file doesn’t get written. If I adjust it manually I keep getting the same sql errors described.

The application is hosted professionally by HostMySite

Thanks - Adrian

Have you contacted HostMySite’s support to find out what user and file permissions are required for files to be able to be written to by PHP?  Also, put the error_reporting() and ini_set() lines in a new PHP file with phpinfo().  The new file should just have the following:

Then access that file in your browser and check the ‘display_errors’ value; it should read “On”.

Hi Derek,

Quick update. I’m still trying to make this work. HostMySite has checked permissions and settings, but I’m still stuck in the same situation. All the db changes go through, but the config.php file doesn’t get written even when giving it 777 rights. We have even tried giving the whole directory 777 permissions, but nothing works. Do you have any ideas?

Thanks,

Adrian

1) Does your host know what permissions are necessary for PHP to write to files or are they just trying?
2) What are the results of my last instructions?

Hi Derek,

I think they do. With every single file set to 777 I think we’re covering all the bases. What do you think?

Well, nothing has really changed ever since I made my first contact to you. Basically, we haven’t left square one yet. Everything I have done has failed. Again though, the db appears to get updated when I run update.php, but everything else just doesn’t happen.

Adrian