Is it possible that you ran the upgrade process twice without restoring the backup database? The query you quote is the very first step in the upgrade process, so I don’t think anything else would have come along to remove that column before this step runs.
Regards,
Alec Smecher
Public Knowledge Project Team
I’ve been looking at upgrade.xml in dbscripts folder, and it looks, as you said, that the first thing to be done is trying to change those values in assoc_type column.
I’m trying to understand the process, the upgrading routine takes de xml file an do as it says, or is just a guide for readers?, I mean, there is any chance the process takes a different course?
The dbscripts/xml/upgrade.xml script is what OJS runs to perform the upgrade. I’m wondering if maybe there’s a third-party plugin that’s causing trouble? Maybe causing the main upgrade process to try to execute twice for some reason?
Regards,
Alec Smecher
Public Knowledge Project Team
Well, I just took public folder and config.inc.php, not the plugins folder, to the new location, do you think it would be posible that a third party plugin is causing problems anyway?
On the other hand, it looks like there is some problem with published_articles_stats_migration and counter_monthly_log tables, may you tell me if those tables are related to some plugin, please?
Hi
There is an old error message about those tables, but it turned out that it was because the copy of the database was incomplete at the beginning and those tables weren’t there, now I’m working with a complete version of the database, and the error message is no more.
Anyway, I made a clean installation of OJS 2.4.8-3 in a local environment, and I notice that those tables are not in the database, not in a clean 3.2 installation either, so I wonder if they are related to a plugin, and maybe, if they are related with the problems I’m facing (is a long shot, I guess).
The counter_monthly_log table is obsolete (from a very old OJS2 deployment) and published_articles_stats_migration is created, used and then deleted during an old upgrade process. Does that help?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi
So those tables should not be there, and there is no reason for de upgrade routine to ask for them, right? but, if I delete them, I have an error message asking for them.
Is it possible the problems depends on an incomplete upgrade from 2.7 to 2.4.8-3?, the process was made like a year ago. If that’s the case, there is something in the upgrade routine that is trying to call those tables?
By now, I can tell there was an incomplete upgrade from 2.3.7 to 2.4.8-3, there is not a copy of the original 2.3.7 database, and the upgrade was made like a year ago.
Do you think there is something we can do to fix the problem?
That’s a tough situation, because you won’t have an easy way of knowing what parts of the upgrade were completed and what parts weren’t. If you think your installation is running fine as 2.4.8-3, but it still reports OJS 2.3.7 (due to an incomplete upgrade), you can force it to believe it’s running 2.4.8-3 by adding a new entry in the versions table. Then the upgrade to 3.2.1-1 will start from the 2.4.8-3 scripts rather than the 2.3.7 scripts.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi
I checked out, and there is already an entry for 2.4.8-3 in the versions table. I really don’t see how the upgrade routine could start with those old tables.
Sorry for the late, late response, I had many things to do before I could continue the upgrading.
What makes me think it was an incomplete upgrade is that I was inform that they added manually the entry in the versions table, same as you suggested before, and I think maybe the database still have some old tables that shouldn’t be there, the list of tables is this:
I would suggest comparing the list against a list of tables from a brand new OJS 3.2.1-x installation. There are definitely some OJS 2.x tables that I can see there. Unfortunately it’s hard for me to comment on whether they’ll cause problems or not without some information on what happened during the upgrade process, i.e. the specific error message (which would indicate where in the upgrade process the script stopped).
Regards,
Alec Smecher
Public Knowledge Project Team
Please let start again, the goal is to upgrade to OJS 3.2.1-x, but I suspected there was a problem in the previous upgrade from 2.3.7 to 2.4.8. By now I know that the upgrade was incomplete and they already added the entry in the versions table, so the system “believes” it’s in 2.4.8-3, but the attempt to upgrade crashes.
The list of tables I’m showing you is the list of tables of the 2.4.8-3 database, and it calls my attention that it remains the article_galleys_stats_migration table.
Now, when I tried to upgrade from the (perhaps incomplete) 2.4.8-3 version to 3.2.0-2, there was an error related to published_articles_stats_migration table, and, well, you can see that table is missing.
I know I was not very clear at the beginning, sorry for that, I’m gonna try to replicate the process so I can show you the error message it shows related to published_articles_stats_migration table.
The published_articles_stats_migration table should be created and then removed during the upgrade process. You can safely remove it from your system before running the upgrade. However, there may well be other problems related to the failed upgrade.
Regards,
Alec Smecher
Public Knowledge Project Team