Thread

Thanks, reply on the way.

Hey Tim,

Thanks!!

Has anyone had a chance to take a look at this?

Hi Tim,

We want to get you the best possible solution and to do that, we’ve called in Robin, one of our Software Engineers.

Robin is going to take excellent care of you and once we have a solution to the upgrade problem, we’ll update here with the outcome.

Thanks for your patience on this.

Cheers,

Hi, just wondering if this got solved? If so what was the issue and solution? I’m hitting pretty much exactly the same issue right now…

Hi Supercool,

Tim never followed up with us it seems. Can you tell me a bit more about your problem? Can you read the Wiki on Troubleshooting Upgrade Errors.

Let me know when you are ready to try the upgrade again.

I look forward to your reply!

Cheers,

Aha, well in the end I solved it, but just so you and possibly anyone else who hits a similar issue know, here’s what I did:

I was getting a similar error as the member_id one Tim referenced before, but this time with the exp_template_no_access table. After a refresh I would then get the field_content_type error and the blog_encoding one etc after deleting that column and so on. So I searched in the ud_200.php for references to the table that first threw an error (exp_template_no_access) and found only two lines that dealt with it, so I just commented them out (1158 and 1159). For reference those two lines looked like this:

$Q[] = "ALTER TABLE `exp_template_no_access` DROP KEY `template_id`";
$Q[] = "ALTER TABLE `exp_template_no_access` ADD PRIMARY KEY `template_id_member_group` (`template_id`, `member_group`)";

Then I did the upgrade, it all went through and I manually added that table from a clean install afterwards.

Does that make any kind of sense? I was upgrading from EE v 1.6.9 to v 2.5.3 and disabled all extensions and converted all weird field types to text ones just to be safe.

Hope that helps someone!

Hi Supercool,

Excellent! Thanks for sharing your solution!

Cheers,