Just to be sure, did you do the update by manual ftp?

Next I'm querying 'Under public_html my database files are located under b2evolution/blogs' These files are only to admin the database but are not the actual data that makes up the tables

I think the option to normalise would be good, but you could download a copy of the database if you are concerned that it may get screwed. If you have cpanel access on your host you can use phpMyAdmin to save a copy etc.

The error seems to relate to an old table that doesn't exist in the new version, so you could make a copy of the old database, and delete that table in phpMyAdmin and try updating again.

As long as you have a backup database no harm will come to the old setup.

Just to be sure, did you do the update by manual ftp?

SIGH!
Not working and seems to be stuck with this on both Normalization and Upgrade. I went back to the installer and Normalization claims that all is normalized; however, when I did a check to normalize the below showed up again. In Upgrade same message as before.

Normalizing DB charsets...
Loading module: _core/model/__core.install.php
Loading module: collections/model/_collections.install.php
Loading module: polls/model/_polls.install.php
Loading module: files/model/_files.install.php
Loading module: sessions/model/_sessions.install.php
Loading module: messaging/model/_messaging.install.php
Loading module: maintenance/model/_maintenance.install.php

Another side note: yesterday, I tried to do the backup within the blog. I got stuck with "503" error and it is still claiming to doing maintenance for now 24 hours.... and counting. LOL! Anyway, yesterday, I did delete the maintenance folder as suggested in manual, did a DB repair no problems), and backed up site via cPanel. Perhaps, the issue is the 503 error causing problems??? Is there some way to reset? Don't know what to do anymore.... there is always a problem with installation and the very reason why I avoid upgrading.

Another question and just frustrated with all of this.

Does it make sense to do a fresh DB install?
As long as I have the basic_config.php and media files from the old blog, I should be okay or bad idea??
Some bloggers want to blog again, and have some drafts. What happens to those posts if DB is changed?

For this upgrade I am using PHP 5.6. For the new install I could use PHP 7 or 7.1 -- any problems with using this on the b2evo 6.1x upgrade?

By manual ftp I mean NOT the auto upgrade which can be a probelkm on some servers, I kept getting a 503 error with reasons like timeout and not finding the install.php etc., But renewing all files via ftp sees to work fine.

Creating a new database may get the site running but then you'll hope you can import the old data.

So let me get this.

"Under public_html my database files are located under b2evolution/blogs were the old site is located. I want to test on b2evotest and use the same database which had permission to access it ages ago. in the basic_config.php and permission it directed to 'b2evotest/b2evolution/'. "

Did you create did a new install in a different directory, then direct it to the old database?

My php is 5.4.41 and v6.10.2 works fine and although there were issues with php 7* those seem to be sorted and don't effect new installs, I think :)

By manual ftp I mean NOT the auto upgrade which can be a probelkm on some servers, I kept getting a 503 error with reasons like timeout and not finding the install.php etc., But renewing all files via ftp sees to work fine.

No, I am not using the auto upgrade within the blog software because my version is too old to use it. I manually direct the file location and go through the installer process. The errors that have shown up are at the very last of the install... everything seemed fine until I hit the last page. :(

Creating a new database may get the site running but then you'll hope you can import the old data.

So let me get this.

"Under public_html my database files are located under b2evolution/blogs were the old site is located. I want to test on b2evotest and use the same database which had permission to access it ages ago. in the basic_config.php and permission it directed to 'b2evotest/b2evolution/'. "

Did you create did a new install in a different directory, then direct it to the old database?

Yes, that is correct! :)
Today, I made a copy of the old database, then directed the Installer to this and the same issues arise, unfortunately.

Working with the host right now to see if a backup can be reinstalled. Maybe, just maybe, that will work to my advantage. So close to finishing this with the last page, yet so far.... can't move forward with this not being fixed.

Update. Reinstalled the DB but ran into a NEW issue and the host looked at the Installer program, too, and can't figure out why the problem exists. Any ideas on this new error? Is there a painless and simple way to fix this?

An unexpected error has occurred!
If this error persists, please report it to the administrator.

Go back to home page

Additional information about this error:
MySQL error!

Duplicate column name 'hit_action'(Errno=1060)

Your query:

ALTER TABLE evo_hitlog

CHANGE COLUMN hit_referer_type hit_referer_type ENUM( 'search', 'special', 'spam', 'referer', 'direct', 'self', 'admin', 'blacklist' ) NOT NULL,

ADD COLUMN hit_type ENUM('standard','rss','admin','ajax', 'service') DEFAULT 'standard' NOT NULL AFTER hit_ctrl,

ADD COLUMN hit_action VARCHAR(30) DEFAULT NULL AFTER hit_ctrl

Additionally, these files continually load and never finish like the other files. These same files happens with upgrading. Does anyone have an answer on how to move this along?

Normalizing DB charsets...
Loading module: _core/model/core.install.php
Loading module: collections/model/_collections.install.php
Loading module: polls/model/_polls.install.php
Loading module: files/model/_files.install.php
Loading module: sessions/model/_sessions.install.php
Loading module: messaging/model/_messaging.install.php
Loading module: maintenance/model/_maintenance.install.php
Normalizing evo_antispam... OK
Normalizing evo_basedomains... OK
Normalizing evo_bloggroups... OK
Normalizing evo_blogs... OK
Normalizing evo_blogusers... OK
Normalizing evo_categories... OK
Normalizing evo_coll_settings... OK
Normalizing evo_comments... OK
Normalizing evo_commentsvotes... OK
Normalizing evo_country... OK
Normalizing evo_cron__log... OK
Normalizing evo_cron__task... OK
Normalizing evo_currency... OK
and the rest are OK

UPGRADING:
Upgrading data in existing b2evolution database...
Loading module: _core/model/__core.install.php
Loading module: collections/model/_collections.install.php
Loading module: polls/model/_polls.install.php
Loading module: files/model/_files.install.php
Loading module: sessions/model/_sessions.install.php
Loading module: messaging/model/_messaging.install.php
Loading module: maintenance/model/_maintenance.install.php
Checking DB schema version... 10400 : OK.
Upgrading hitlog table...

HI

"Today, I made a copy of the old database, then directed the Installer to this and the same issues arise, unfortunately."

Was it a choice to direct the installer to the copy of the database, presumably by the basic-config setting, which is not the installer? Do you not have the option to upload the old data to the new and clean database from phpMyAdmin for example?

"Working with the host right now to see if a backup can be reinstalled."
A back of what, the database? I thought you have a copy
A back up of b2evo> I thought this was a new test install in a different directory

I've a suspicion that someone else may respond to your problem who is more proficient on this issue, as I indictated I have had a few problems that were solved but without a clear argument :(

Was it a choice to direct the installer to the copy of the database, presumably by the basic-config setting, which is not the installer? Do you not have the option to upload the old data to the new and clean database from phpMyAdmin for example?

Whatever is in the basic_config is how the installer accesses the DB so that it can upgrade the files.
Not sure if a new/clean database would make a difference if there is a problem with the old one. Whatever the case, I can only hope that someone with experience can help with this problem because I would like to get it done.

Hi

The /config/_basic_config.php/ only has the database path, name and password etc. so it will connect to any database you like, even mine if I were to give you my details.

Apart from the database version update, the other issues the update will have to do is.

1. Check the character set is now UTF-8
   • check the tables are the same in terms of name, whence I would imagine, new ones would be created and given default values, * tables may just have field names changed and or default vales changed
   • some obsolete tables deleted.

You may like to read
http://forums.b2evolution.net/v6-or-v5-falied-to-upgrade-from-v and
http://b2evolution.net/man/unexpected-error-during-upgrade which Francois means in the above linked post

I can only hope that someone with experience can help with this problem because I would like to get it done.

I'm sure someone will :)

Reinstalled DB and made another clean copy.
I ran the install on the test site, again, but did the following and NO ERROR issues happened because I did the following:

THIS SHOULD BE PUT IN FOR INSTRUCTIONS WITH UPGRADE & ERRORS!!!

1. Go MyAdminPHP. See if there is a large figure in these two areas, empty HITLOG and SESSIONS, reducing them to "0".
2. Refresh Installer page and Upgrade.

The above apparently avoids all ERROR messages and the installer works perfectly without any problems and it has nothing to do with "previous install" with blame on the user as suggested in the above links (at least not in my case). This is a simple thing to do and avoids wasted time. I wish that I had done this before. Nonetheless, I hope that this will help other people with their installs without frustration and errors.

So it looks like the file was too big and overloaded with data. I usually delete those and the items_version table at lrast once a month and back up the data base.

I suppose it is possible to make this automatic via some cron job but the manual method keeps me in touch with the detail.

It's a relief that you have found the problem, just a pity such a problem couldn't be detected at the initial upgrade and a suitable error message displayed.

But hey! It's a free application that many people have spent tens of thousands of hours on, there is always going to issues that have not been accounted for. But the previous install does include the database and if that is the issue it could be argued it's a user issue. :)

All the best

It's a relief that you have found the problem, just a pity such a problem couldn't be detected at the initial upgrade and a suitable error message displayed.

Yes, exactly my point. I have avoided upgrading because there is always a problem. I believe that this simple procedure has always been the possible
Issue. A simple message in upgrading to clear certain DB data should be displayed to avoid wasting ppls time and great frustration. Seriously, I have considered shutting down the site many times, because this should be a simple matter to upgrade.

I have indeed felt frustrated over upgrading, especially with the auto, which never works for me, but in my case it seems that maybe the server, which is a bit down-market, can't cope with all the delays. The database size, timeouts, php versions etc. can all upset the install.

But given how good the product is, how much work goes into making it, then as you have found, user ingenuity can resolve the problem.

I think it's too much to expect that Francois and all could anticipate alll the server setups and database table sizes due to old sessions being stored, so don't be harsh on the developers :) and be happy you have persevered and helped to show the way.

Emptying unwanted records from the database, as you have done is a wise thing to do, so it may well be a useful bit of advise to let those upgrading be reminded of.

Thanks again for your discovery.

EDIT Update
Just decided to clean the session table etc. and export my database and noticed I have no entrees in my hitlog so I've turned off hit logging in the back office. Do you track your hits? as if not ? :)

Of course the problem still may occur on some server set ups if a site owner wants to keep all the hit and session log info :(

I think it's too much to expect that Francois and all could anticipate alll the server setups and database table sizes due to old sessions being stored, so don't be harsh on the developers :) and be happy you have persevered and helped to show the way.

I have used this program for 10 years and counting,... so, I have seen people come and go, and not a newcomer to this! I have also used other database programs for 20+ years and upgrading has gone smoothly. This one has always had some kind of glitch with the installer and my frustration is warranted and the reason why I wait years to upgrade. Hopefully, the new programming with this upgrade will be worth it. :)

Always the same problem: if you have started and upgrade and it stopped for any reason, you have to either finish it or RESTORE A BACKUP. This is particularly critical with older versions (<6). If you have left an (older) upgrade half done, then yes, all other upgrades down the road will have problems.

However, if you follow the instructions, it will work fine.

I have tested this with installing the version http://b2evolution.net/downloads/4-1-4-stable then upgrading to 6.10.2, and it works without errors as you can see on the attached screenshots.

@yurabakhtin

Hi two questions

1. Was the update manual ftp not auto and
2. Was there a huge3 database that may have instigate some sort of timeout

15

I have indeed felt frustrated over upgrading, especially with the auto, which never works for me, but in my case it seems that maybe the server, which is a bit down-market, can't cope with all the delays. The database size, timeouts, php versions etc. can all upset the install.

12

THIS SHOULD BE PUT IN FOR INSTRUCTIONS WITH UPGRADE & ERRORS!!!

Go MyAdminPHP. See if there is a large figure in these two areas, empty HITLOG and SESSIONS, reducing them to "0".
Refresh Installer page and Upgrade.

Hi @amoun,

1. It was a manual ftp update.
2. No, it was an update with default demo content.

Thanks @yurabakhtin

I'm pretty sure the problems are often that some server setups are a bit slow and timeout, so a big database just adds to the problem. On my ancient shared server (php 5.4.41 mysql 5.1.73 cll ) etc I can not auto upgrade. It always stalls once the upgrade script is automatically called giving me a 503 and 404 error that the /install/index.php cannot be found.

I'm happy :)