Thread

Hi,

I’m in the process of laying the groundwork for a significant redesign of a relatively high-profile EE installation for a client. The first task is to get the very old installation of 1.6.8 up to date. I’ve failed a few times today, and I’m at the point where I need some help.

Just to run through the timeline of my efforts so far:

1. Attempt to upgrade from 1.6.8 to 2.5.2

(I’m working from a clone of the site — discrete codebase and DB.)

Result: MySQL errors (inconsistent ones).

2. Clear out database, restore backup, restore config file, re-attempt.

Results: Same.

3. Clear out DB, restore, attempt upgrade to 1.7.3 instead.

Results: Success!

4. Attempt to upgrade from 1.7.3 to 2.5.2

Results: MySQL errors, but this time consistent ones.

5. Rinse; repeat.

The main culprit is this:

A Database Error Occurred
Error Number: 1060

Duplicate column name ‘field_content_type’

ALTER TABLE `exp_weblog_fields` ADD COLUMN `field_content_type` VARCHAR(20) NOT NULL default ‘any’

Filename: updates/ud_200.php

Line Number: 1700

Not knowing much about why this might be failing, I went in and deleted this particular column from the table, at which point I get a new error:

Error Number: 1091

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

ALTER TABLE `exp_weblogs` DROP COLUMN `blog_encoding`

Filename: updates/ud_200.php

Line Number: 1700

A subsequent refresh (and all future refreshes) of the window brings us back to the original field_content_type error.

Googling for the error brings up relevant threads in the EE forums (most notably this one), but there weren’t many concrete suggestions I hadn’t tried. One of them suggested turning off Javascript, so I tried that to no effect.

It might be worth noting that a couple of times I got the “the installer can’t find these template files” message, even though I confirmed that the files existed. It seemed relatively unimportant, since I can restore the templates later if they are lost, so I clicked the “this is moot” link to proceed.

I read the “Troubleshooting Upgrade Errors” page, and nothing seems to apply. I am not using Firefox, and there are no funky customizations to my config file.

Halp!

Hi,
Just a few thoughts:

- what add-ons—modules, extensions are installed? and are they all upgraded?
- any custom code?

EE support should be along shortly…

[update] see that your discussion title says 1.7.3

I just tried again, this time removing all third-party modules and extensions.

I continure to get a MySQL error, the first one being:

Error Number: 1091

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

ALTER TABLE `exp_member_data` DROP KEY `member_id`

Filename: updates/ud_200.php

Line Number: 1700

... and after a refresh it starts showing the familiar field_content_type error.

Hey Tim,

I am sorry to hear you are running into this problem.

Can you tell me the size of your database? It may be that we are not triggering the “Large DB” update, not sure why that would be the case, but that is one of the major steps in the ud_200 file.

Can you also try something for me? Can you roll back again? Then check your database for “field_content_type”? Is it there? If it is, then unfortunately you are rolling back and importing a broken DB. Is it possible that you took a backup after a failed upgrade?

If it’s a good DB prior to the upgrade then it will not have field_content_type and will have blog_encoding.

Does that make sense?

Cheers,

Do you mean size in terms of records? We have about a thousand entries, with perhaps an average of 6-10 comments on each (could be wrong about that — can’t seem to find the comments section of the CP), and about 13k member accounts.

Or in terms of actual file size? The DB is about 104MB.

Looking at my pre-upgrade-attempt DB backups (both the 1.6.8 & 1.7.3 backups), I do not see the field_content_type column in the exp_weblog_fields table.

Counting entries directly from the DB:

exp_comments: 20,426 entries

exp_members: 13,313 entries

exp_weblog_data: 899 entries

Just checked the live DB to be absolutely sure and it does not have field_content_type either.

Does it look like the Large DB update isn’t kicking in? How do I fix that?

Hey Tim,

The Large DB gets triggered at 150 Megs. You are close enough that I would like to trigger the large DB update. I can explain more about my reasoning here if you wish, but I think this may be the solution.

So what you would do is roll back once again to the beginning before any upgrade attempts. We are going to go through the update again but before that I would like you to edit a file.

In system/installer/updates is the ud_200.php

On line 30 you will find this:

var $large_db_threshold  = 150; // database size in megabytes

Go ahead and lower that value so we can trigger the Large DB upgrade. Maybe make it 100 Megs since your DB is 105 Megs.

Then upload all the files again and run the update.

This is going to require you have command line access during the install to run a shell script which will then make the major modifications to the DB that bring your install from the world of 1.X to the world 2.X.

I believe the process should be pretty smooth after that.

Does this make sense? Please let me know when you have had a chance to test this out.

Cheers,

Thanks for the info.

While I seem to have successfully run the shell script (I got the following message: “Large Database Conversion Completed: Please return to the browser to finish your upgrade.”), upon returning to the installation page I"m not sure what to do — should I refresh the page with the query string intact? Should I return to the beginning of the process?

In any case, I tried both, and I can’t get past the “Your database is too large” message.

I just noticed that an error possibly occurs during the shell script execution — I don’t know enough to say if this is a problem or not:

Starting Large Database Conversion
UTF-8 Conversion (Step 1: Dumping database with current charset)
UTF-8 Conversion (Step 2: Importing database with UTF-8 charset)
UTF-8 Conversion (Step 3: Removing database dump)
DST Conversion (Step 1: Reading queries)
read: 33: Illegal option -d
DST Conversion (Step 2: Writing temporary SQL file)
DST Conversion (Step 3: Importing temp file, this may take several minutes)
DST Conversion (Step 4: Removing temp file)
Large Database Conversion Completed: Please return to the browser to finish your upgrade.

(Is the “Illegal option -d” expected?)

ARG.

So I tried running the script again using bash this time, and it seemed to execute properly. I returned to the installer, refreshed the page, and it started proceeding!

BUT THEN…

Error Number: 1060

Duplicate column name ‘field_content_type’

ALTER TABLE `exp_weblog_fields` ADD COLUMN `field_content_type` VARCHAR(20) NOT NULL default ‘any’

Filename: updates/ud_200.php

Line Number: 1700

Just to be thorough I started from scratch again.

Go this error (on an unstyled page):

{"error":"
Error Number: 1091<\/p>\n\n

Can't DROP 'member_id'; check that column\/key exists<\/p>\n\n

ALTER TABLE `exp_member_data` DROP KEY `member_id`<\/p>\n\n

Filename: updates\/ud_200.php<\/p>\n\n

Line Number: 1700<\/p>"}

After a refresh I get the familiar field_content_type error.

It’s probably not helpful, but I’ll note that the second to last attempt seemed to make much more progress than any other attempt.

Hello Tim,

Man, I am so sorry this has been such a headache for you. Ugh!

Please be on the lookout for an email from EllisLab. I would like to get a Developer to take a look.

Cheers,