Screenshot

gave it another whirl just in case, got the error: "Duplicate column name 'ufdf_required'(Errno=1060)"
ALTER TABLE evo_users__fielddefs ADD COLUMN ufdf_required enum("hidden","optional","recommended","require") NOT NULL default "optional"

This was not a clean install of course. So I dropped the whole table, started from the beginning and back to error#1 "Table 'evo_items__item_settings' already exists(Errno=1050)"

Update#2: Tried another clean upgrade to 5.x, same result: Creating table for a specific post settings... evo_items__item_settings exists.

@tilqicom for some reason your database is not 4.x, did you try a failed upgrade anytime before this one?

The table evo_items__item_settings was introduced in version 5, thus until version 4.1.7 (last one of the v4 series) it didn't exist. Please check the screenshot below, your database version is 10200, however, you already have tables from the following version (10300) on it.

This is not an issue of the current upgrade, so the first thing to figure out is how evo_items__item_settings ended up in your database, in order to find out the inconsistency and solve it before to going further with the upgrade. If not, myabe errors like this will keep appearing one after another.

The second error you commented is just a consequence of the first failed upgrade attempt.

@mgsolipa I dont remember really, but quite possibly. Thanks for the info, I assume, I'll try dropping the items_item_settings and try another clean upgrade.

Now it says Duplicate column name 'hit_action'(Errno=1060) . Funny thing is, i dont have a column like that.
error screenshot : http://i.imgur.com/rX4PVDz.jpg

table screenshot attached.

PS for the forums: I ve notcied that we cant add more than 1 image ?? and the img codes are not working.

<img src="http://i.imgur.com/rX4PVDz.jpg" alt="" title="" />
[img]http://i.imgur.com/rX4PVDz.jpg[/img]

@tilqicom If you click "Preview/Add file" you can add additional files. (It was designed that way for people who have JS turned off. We'll add more Ajaxy features soon).

Good to know :P What about the actual problem ? I think I am about to give up, these errors doesnt make any sense

You obviously have a database that is not a clean 4.x database and that has been half upgraded to something we don't know.

I think this case is thoroughly documented here: http://b2evolution.net/man/unexpected-error-during-upgrade

I know and I've read there. I ve tried everything, like trying to go through 5.x first, that didnt work either. I commented out problematic parts of the upgrade script but only more errors followed up.

The thing is the errors it throws doesnt make anysense, The tables / columns it says it exists, they dont. And some tables / columns that DONT exists, the script thinks they DO exist and skip them. It's like the opposite day for the script, dont know why.
I even tried to walk through manually running SQL queries, that wasnt very viable either. So I dont know what am I supposed to do here.
Do a clean 6.x install from scratch and import posts using Alex's importer ? - not sure if thats gonna work either. I feel like I am out of options. And I cant run 4.x on my new server which is on php 5.5. I'm afraid I am gonna end up switching over to wp

If MySQL says a table exists and you say it doesn't exist, then it means you are not looking at the same database.

Let me insist: even in your screenshot it is a MySQL error message that you see. Do we trust MySQL?

Clearly you probably have multiple DBs on your server and you probably have them mixed up.

Check what it says at the bottom of your install menu screen.

Yea I do have multiple DBs on the same account, actually 4 other b2evo databases under same account for test installs.
But even before posting, I double, triple, quadruple checked the name. I cant understand how the other dbs can interfere with it, Its so weird, doesnt make any sense. Gonna give it a one last go with a clear head in under another account see if that changes anything.

The problem was definitely with a previous failed upgrade.
I know it's my fault that I did not rollback myself after a failed upgrade (dont know why, dont even remember) , but I feel like its doable to implement a rollback mechanism to undo the entire process if the upgrade fails.

I had to go step by step, it was painful and felt rather patchy, but I hope everythng will be allright :) I ran into some problems along the way and pretty sure I found a tiny bug or two somewhere between 11000 - 11300 but I was too tried to note it down.

Anyway, still got a lot to do - install default skins and stuff... lets see how this goes.

Update: It basically "works", the blogs and posts load and stuff. But seems like a lot of things went wrong along the way. Posts types changed to "custom_Blogname" for some reason. Created like 10s of empty custom fields for posts and ignored existing ones, and some character problems. I gotta start from scratch end double check those before initializing script, but sounds like a lot of trouble for the time being.
I wish there was a simpler way, like creating a clean 6.x install and importing the posts and stuff later. Maybe I'll give sam2kb's importer a shot, it might still work with some modifications

What am I missing below ? No column named "emlog_success" exists, even in a clean 6.2.6 install

task_begin( 'Upgrading email log table...' );
// Get old values of emlog_success field
$SQL = new SQL();
$SQL->SELECT( 'emlog_ID' );
$SQL->FROM( 'T_emaillog' );
$SQL->WHERE( 'emlog_success = 0' );
$email_failed_logs = $DB->get_col( $SQL->get() );
// Change a field emlog_success to new format
$DB->query( 'ALTER TABLE T_emaillog CHANGE emlog_success emlog_result ENUM ( "ok", "error", "blocked" ) NOT NULL DEFAULT "ok"' );
if( !empty( $email_failed_logs ) )
{ // Update only the failed email logs to new values
// Do NOT update the success email logs, because we already have a result type 'ok' as default
$DB->query( 'UPDATE T_email__log
SET emlog_result = '.$DB->quote( 'error' ).'
WHERE emlog_ID IN ( '.$DB->quote( $email_failed_logs ).' )' );
}
task_end();

What do you mean with "clean 6.2.6 install?"

Do you mean you made a clean 6.6.2 install? In this case, why do you upgrade? Are you trying to upgrade to 6.6.3?

You don't really describe what you are doing so it's hard to know what you are asking about.

I made a fresh install with sample data for testing purposes and compare tables structures etc, to intervene manually if needed.
I managed to upgrade to 6.6.2, It's working overall. There are some things needs to be done to get it in full shape (errors from 4.x changes to category objects etc, but I think I can handle it.
The culprit was the previously failed upgrade obviously. Gotta make sure that never happens again, also I should upgrade more often :D 4.x was like 3 years ago or something ?
I really dont wanna give up on b2, I like to have one foot here to see where it goes.
Anyway thanks for the help.

PS: Cant you add simple checks to upgrade script so that it checks if table exists before trying to create table ? For odd cases like mine, that would help a lot, and could come handy in other situations maybe. You could compare table structures if you wanna make sure the existing table is the one upgrade script is trying to add.

@fplanque wrote earlier:

What do you mean with &quot;clean 6.2.6 install?&quot;

Do you mean you made a clean 6.6.2 install? In this case, why do you upgrade? Are you trying to upgrade to 6.6.3?

You don't really describe what you are doing so it's hard to know what you are asking about.

There are already tons of checks in the upgrade process to try to recover from many common cases.

We have already started adding checks before creating tables. But in many cases a table is created in a version and then modified in another. This will not make it bulletproof.

As there number of versions and the DB complexity increases, the number of variations where someone could have abandoned a half applied upgrade increases exponentially.

The only clean way to work is to restore a backup it at some point you start to abandon an upgrade in the middle of it.

Glad I'm not the only one who had such errors when I went from v5 to v6.

Not sure exactly what I went through but as I had an old database copy locally with just a few posts missing, I eventually dumped the remote database and created a new empty one and installed v6.1 Then imported the old database. Ended up with a UTF-8 mismatch but ignored it and it went away.