How to check if you DB is ready for OJS3?

I see in forum that usually migration errors is due:
a) Partial migration corrupts the DB.
b) Doing migration without setting installed=Off in config.inc.php
c) Permissions issue.

I checked this twice in this old DB and I’m still getting an migration error.

As is explained in this forum setting config var to “debug=On” and running upgrade from commandline gives more info.

In my case log shows this:

Query: INSERT INTO review_round_files (submission_id, review_round_id, stage_id, file_id, revision) SELECT afm.article_id, rr.review_round_id, 3, afm.file_id, afm.revision FROM article_files_migration afm, articles_migration am, review_rounds rr WHERE am.revised_file_id = afm.file_id AND rr.submission_id = afm.article_id AND rr.round = afm.round failed. Duplicate entry '373-48-452-1' for key 'review_round_files_pkey'
1062: Duplicate entry '373-48-452-1' for key 'review_round_files_pkey'
							ADOConnection._Execute(INSERT INTO review_round_files (submission_id, review_round_id, stage_id, file_id, revision) SELECT afm.article_id, rr.review_ro..., false)% line 1051, file: /var/www/html/lib/pkp/lib/adodb/adodb.inc.php
						ADOConnection.Execute(INSERT INTO review_round_files (submission_id, review_round_id, stage_id, file_id, revision) SELECT afm.article_id, rr.review_ro...)% line  440, file: /var/www/html/lib/pkp/classes/install/Installer.inc.php
					Installer.executeSQL(INSERT INTO review_round_files (submission_id, review_round_id, stage_id, file_id, revision) SELECT afm.article_id, rr.review_ro...)% line  435, file: /var/www/html/lib/pkp/classes/install/Installer.inc.php
				Installer.executeSQL(Array[111])% line  396, file: /var/www/html/lib/pkp/classes/install/Installer.inc.php
			Installer.executeAction(Array[3])% line  265, file: /var/www/html/lib/pkp/classes/install/Installer.inc.php
ERROR: Upgrade failed: DB: Duplicate entry '373-48-452-1' for key 'review_round_files_pkey'

I can’t find any reference in to 373-48-452-1 in db or in the original files.

I found a post that show a very similar error, but the workaround is not working in my case:

Any suggestion about how to find the offending row/article?

As I asked in the first post… what about an script to check the DB integrity?
Most of the questions published by sysadmins in this forum will be selfanswered.

Cheers,
m.

1 Like