Error Restoring a course in newly upgraded moodle 2.6.2+ instance

Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by james mergenthaler -
Number of replies: 6

We upgraded our moodle instance from  2.2.4 to 2.4.9 to 2.6.2.  When I backup and restore one of the courses, I am getting a error:

"Default exception handler: Error writing to database Debug: Duplicate entry '575744' for key 'mdl_qtypmultopti_que_uix'\nINSERT INTO mdl_qtype_multichoice_options ". 

The table has approx. 62000 records, the number referenced in the error message is the questionid in the mdl_qtype_multichoice_options table.

I have created new backups without user data for a couple courses on the site, each restore results in the same message.

I was able to create a new course, add a quiz , a forum and assignment, back it up and restore without problem.

When I added a couple quiz questions, one multiple choice, one T/F, backed up and restored and it failed the same way. 

error message generated from moodle when trying to restore a course.


I am using MySQL 5.5.24.

Thank you for ideas on solving this.


Average of ratings: -
In reply to james mergenthaler

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by james mergenthaler -

I turned on Full debugging in the moodle instance, created a new backup from an existing course, without user data, with defaults - with no problem.

Restored the new backup file to existing category and failed.

image of detailed fail message generated when restoring a course backup

Average of ratings: -
In reply to james mergenthaler

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by Shirley VerStraete -

I work with James Mergenthaler. We have gone through many attempts to upgrade from 2.2.4 to 2.6. 

We continually get error message/s: 

1. mdl_assign already exists - line 432: of db/mdl_database.php: ddl_change_structure
OR
2. question_match already exists

Our current server environment is:  Moodle 2.2.4 (Build 20120706), MySQL 5.5.24, and PhP 5.3.13. We run these on a WAMP server along with two other instances of Moodle. We have successfully been able to upgrade one Moodle instance on this server  to 2.6.2+ (build 20140327). The other instance is our test instance where we have been making the following 6 attempts to upgrade.

The differences between the successful upgrade instance and the unsuccessful upgrade are:

  • the successful upgrade instance has only courses created by our internal users within our own organization. It has a small database.
  • the unsuccessful contains courses created by third-party vendors and loaded onto our server. The third-party vendor courses have been working successfully on our Moodle 2.2.4 server for the past year. The database on this Moodle instance is very large > 600 MB.

Test #1
changed php/php.ini - memory_limit to 128MB
changed mssql/bin/my.ini - max_allowed_packet which had been set to 32MB was changed to 64MB
Test result: failed with error #1.

Test #2
Went into PhpAdmin and dropped the old database and created a new database with the same name as the old database and with utf8_unicode.
At this time Moodle 2.3.11 Code was in place.
Went to MySql command line and restored the database.
Went to Moodle and did the Upgrade and Plugin Check for Upgrades.
Progress bar displays
Test result: Error #1 displays.

Test #3
Dropped the database in PhPAdmin and created a new database with same name as old database.
Copied Moodle 2.4.9 code and restored the 2.2 database.
Browsed to the site - Server check indicates all is OK, nothing listed at bottom of page regarding questions.
Checked for available plugin updates and Continued
Progress bar completed. Browser continues to spin for a very long time (20 minutes)
Browser stopped spinning. We refreshed the browser and we get Error #1.

Test #4
Dropped the database using PhPAdmin.
Purged the caches and restarted all services.
Created a new database with same name.
Copied Moodle 2.6.2 code into Moodle on server.
Browsed to the site and progressed through the Upgrade.
This time after the Progress bar has completed, the list tables begin to display then we get Error #2.

Test #5
Repeated steps of dropping table, purging caches, restarting services.
This time we use a smaller backup of the database (350MB) whereas the database we've been testing with is 650MB,
We also try copying in Moodle 2.4 to the Moodle folder on server.
Result: Progress bar completes. Table list begins to display and we get Error#1.

We do have a couple more test scenarios to attempt -

We will check that all courses in the Moodle 2.2 instance are indeed compatible with Moodle 2.2 (hypothesis: a third-party course may contain quiz questions that did not go through the Quiz Engine Upgrade.)

We will try deleting the offending table (either mdl_assign or question_match (whichever the error indicates. This however is not desireable because it is our understanding that by deleting the table we would no longer have those questions or assignments available for use in the 2.6 version.

Does anyone have any other suggestions or hypothesese we can tyr?


Average of ratings: -
In reply to Shirley VerStraete

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by Shirley VerStraete -

P.S.

On our production server (which we are desiring to upgrade) we have run the Quiz Engine Helper and are told that "Everything has already been converted" and "No upgraded attempts that can be reset".


Average of ratings: -
In reply to Shirley VerStraete

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by Ken Task -
Picture of Particularly helpful Moodlers

One suggestion ... am guessing the 'hyperjump' from 2.2.4 to 2.6.highest is perhaps a jump too much.

Make a duplicate of the 2.2.4 site ... copy of the DB (by another name), copy of the data directory but acquire the 2.3.highest code via git.   http://docs.moodle.org/27/en/Git_for_Administrators

Use 

git branch --track MOODLE_23_STABLE origin/MOODLE_23_STABLE

and

git checkout MOODLE_23_STABLE

Copy the config.php file from the 2.2.4 site to the 2.3.highest code folder.  Edit the config.php file to reflect changes (DB name, data directory) and add the lines for debugging.   Then in the 2.3.highest code folder, from the command line, go to admin/cli/ and issue:

php upgrade.php --non-interactive

After the upgrade has completed, use a browser and go to the cloned site, login as an admin user, and then use the Assignment Upgrade Helper as well as the Quiz Upgrade tool.

If successful, use git again to upgrade the cloned site from 2.3.highest to 2.4.highest - using MOODLE_24_STABLE in commands above.   Check site.  IF all OK,  repeat only this time from 2.4.highest to 2.5.highest - using MOODLE_25_STABLE in commands above.   Check site.  Repeat with git taking it to 2.6.highest - using MOODLE_26_STABLE.

Yes, it sounds like a lot but not really.  Have 'marched' a 1.9.16 site through 1.9.highest, to 2.2.x, 2.3.x, 2.4.x, 2.5.x, to a 2.6.x in a matter of 4 hours.   Most of that time taken up by running backups at each phase.  The actual acquisition of code - a matter of minutes ... the actual upgrade - a matter of minutes also.

'spirit of sharing', Ken


Average of ratings: -
In reply to Ken Task

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by Shirley VerStraete -

Ken - thank you for your suggestions and clear instructions.

I don't really understand why you recommend going to git instead of using the 2.3, 2.4 etc. downloads.

What do you see being the difference?

Thanks,

Shirley

Average of ratings: -
In reply to Shirley VerStraete

Re: Error Restoring a course in newly upgraded moodle 2.6.2+ instance

by Ken Task -
Picture of Particularly helpful Moodlers

Pardon this brief history of experience with open sourced apps (joomla, wordpress, drupal,  and Moodle) ...

Learned early on that one of the Admin criteria to check for open sourced AMP stack apps is the ability of the admin user to keep the app updated and secure easily.  Most apps have similar install instructions, but that's tip of the iceburg if one desires to continue to use. 

Joomla, as an example, had .tar.gz patch packages for download to upgrade (still do).  The tar.gz patch packages replaced files that needed updating/upgrading, but to use them admin user (who also needed to have root access to the server) had to use command line (most of the servers I ran were retired Windows work stations from the Business Office and didn't have the resources to run a GUI desktop in Linux.  GUI desktop on a Linux server, BTW, didn't have anything that couldn't be done via command line).  Learned during 'world wide wait' days (dial up internet via POTS) that every time one transfered something ... from server down to work station, only to have to upload from work station to server ... there was potential for crackle on the line which would corrupt the transfer - or due to the shear number of files/size of files, transfer may not accurately transfer everything.  Besides that, most inefficient ... download only to turn around and upload.   Server to server is best.

Like most users, started with the download zip package, unzip locally, FTP back up to server.  Didn't always work.   Besides that had to run yet another service (FTP) which also needed updating/fixing from time to time + users + access restrictions, etc..   Enter secure copy (scp).   Better, but still down then up.

Moodle used to have a CVS system for updating.   Used it for years and had only one problem when upgrading a Moodle.   Things change .... enter git.  IMHO, best yet.

One reason ... transfering code files from server to server and like Joomla's patch package acquiring ONLY the files that need to be updated/changed - not having to download the whole thing to turn around and upload via FTP.

Once a Moodle is installed/setup using git, how easy is it to login via terminal (ssh), change into the moodle code directory and type: git pull [ENTER].

How easy is it to then to upgrade via command line:

cd moodlecode/admin/cli/

php upgrade.php --non-interactive [ENTER]

Once one learns a little git, eliminates some of the pitfalls of FTP, ownerships/permissons, etc.   Faster.  More efficient, etc..  Update a moodle within a series (version) or upgrade a moodle to the next highest STABLE version in a matter of minutes.

Just my 2 cents, of course.

'spirit of sharing', Ken

Average of ratings: -