OJS 1.1.8 TO 2.1

[marcio]

When I try to import my old OJS magazines to the OJS new version in page'Import from 1.x version' , appears a error message
DB Error: Table 'ojs.journals' doesn't exist
DB Error: Table 'ojs.sessions' doesn't exist

What I have to do???

Marcio

[asmecher]

Hi Marcio,

Is your OJS 2.1 deployment fully installed and configured? If so, and you're not sure what the problem is, feel free to contact us at pkp-support@sfu.ca with specific details about your system.

One thing to try: Some older deployments of OJS 1.x connect to the database in include/db.php as follows:

Code: Select all

// initiate a new database connection
 $db = new db_connection($db_config[type]);
if($db->connect($db_config[host], $db_config[port], $db_config[uname], $db_config[password], $db_config[pconnect], $db_config[name])) {
        $db_connected = true;
} else {
        $db_connected = false;
}

This can disrupt OJS 2.x's own database connection; you can prevent this from happening by commenting out the above section of code before performing the migration.

Regards,
Alec Smecher
Open Journal Systems Team

[marcio]

Thanks, but I have already found out a solution, to upgrade for 2.x version it must upgrade the 1.x version for 1.1.10 version first.....

seya and thanks

Marcio

[mpatti]

Hi,

I’m using OJS to run a journal site.

This is being run on a Windows 2003 server, 32-bit, with IIS 6 hosting the site, and MySQL 5.1 storing the data (also on the server).

I had to restart my server last night, and after the restart, the MySQL service was hung in a starting state. To correct the problem, I took a backup of:

ib_logfile0
ib_logfile1
ibdata1

and then deleted those files from C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data

I then restarted MySQL (which took around 20 minutes to complete), which created new files with those same names, but with a drastically smaller size for the ibdata1 file (10,240KB, down from 26,624KB).

After the service restart, I went to the site homepage, and saw the following error message:

DB Error: Table 'ojs.sessions' doesn't exist

I saw a posting here about that issue (viewtopic.php?f=8&t=734), but I’m not sure this applies to my situation. I haven’t performed any upgrades recently.

When I load the database in MySQL Workbench, and run the query “SELECT * FROM ojs.sessions;” I’m getting the same error message “Error Code 1146. Table ‘ojs.sessions’ doesn’t exist.

I am not a MySQL expert, but I’m stumped by this. If I can browse to the table in MySQL Workbench, how can it not exist? The table definitions are stored under C:\Documents and Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data\ojs, and in that folder, I see all the .FRM files for the tables.

I’m at a loss as to how to restore my data, if it has in fact been lost. Do I just need to roll back to the archived copy of ibdata1 and try again?

Thanks in advance for your help with this.

[asmecher]

Hi Michael,

You might be better off exploring some MySQL-related forums for this -- your MySQL install now has inconsistent files and that's why it appears to be behaving irrationally. I'd suggest using the MySQL repair tools (e.g. mysqlcheck) to see whether the damage is repairable. The "sessions" table itself is unimportant (it can be recreated without problems) but it's likely that other data will be missing as well.

Regards,
Alec Smecher
Public Knowledge Project Team

[JasonNugent]

Hi Michael,

In addition to Alec's advice, it sounds like your MySQL installation is using Innodb tables for data storage. That's what was in those ibdata files. MySQL will always maintain the metadata files for the tables outside of the ibdata files (those are the .frm files you found), but it merges *all* Innodb data for a database in a single file. Moreover, it uses a single ibdata storage set for *all* of your databases, not just your OJS one. So you probably need to restore from backup. You may even have to roll back to an older snapshot for your other databases, if you have any.

The best way to solve these sorts of problems is usually to re-import from a mysql database dump, which is storage engine agnostic.

Regards,
Jason