Details

1/ install 1.9.x and all different resource types
2/ add several more resources
3/ go to DB and change the last two course_modules.instance fields to point to different resource (one from the same, other from different course)
4/ upgrade to 2.2.x
5/ verify the resources were upgraded correctly

1/ install 1.9.x and all different resource types
2/ add several more resources
3/ go to DB and change the last two course_modules.instance fields to point to different resource (one from the same, other from different course)
4/ upgrade to 2.2.x
5/ verify the resources were upgraded correctly

Petr Skoda
added a comment - 17/Nov/10 9:21 AM Hello,
the upgrade stops because there is a serious inconsistency in resource tables. Did you encounter any other problem during the upgrade? Did you install any contrib module in 1.9 or modified any files?
Petr Skoda

No problems or errors during install.
I do have a couple of added modules, but my other install with the same modules upgraded. I will try to backup and restore to a clean 1.9 install and then upgrade.

Timothy Guy
added a comment - 17/Nov/10 9:06 PM No problems or errors during install.
I do have a couple of added modules, but my other install with the same modules upgraded. I will try to backup and restore to a clean 1.9 install and then upgrade.

When update from 1.9.10+ to 2.0.1+ all clean, only Feedback (1.9.10) extension.... process crash with "Unknown error upgrading mod_resource to version 2009062600, can not continue. When upgrading to Moodle 2.0".
Server is Debian Squeeze, Apache 2.2 & DB on PostgreSQL.

I had the same error. But just prior to that error, I had an error with a duplicate in resource_old which I traced to a resource that was repeated twice with the same instance number in a same course. Deleting both (in the 1.9 database) and recreating one fixed the problem... but I had to restart the upgrade from 1.9.11 to 2.0.2 from scratch

there were 4 of these duplicate situations which I could get one by one by re-running the upgrade from scratch (very long because very big database) or by using this shell script, FWIW

for i in

{1..500}

do
mysql -p moodle -e "select count as c,id,course from mdl_course_modules where course=$i and module=12 group by instance order by c;"
done

and looking for 2's in the first column and then looking at the instance , then the corresponding record in mdl_resource and find the culprit to delete both instances in that course (and recreate it)

Bruno Vernier
added a comment - 25/Mar/11 3:38 PM I had the same error. But just prior to that error, I had an error with a duplicate in resource_old which I traced to a resource that was repeated twice with the same instance number in a same course. Deleting both (in the 1.9 database) and recreating one fixed the problem... but I had to restart the upgrade from 1.9.11 to 2.0.2 from scratch
there were 4 of these duplicate situations which I could get one by one by re-running the upgrade from scratch (very long because very big database) or by using this shell script, FWIW
for i in
{1..500}
do
mysql -p moodle -e "select count as c,id,course from mdl_course_modules where course=$i and module=12 group by instance order by c;"
done
and looking for 2's in the first column and then looking at the instance , then the corresponding record in mdl_resource and find the culprit to delete both instances in that course (and recreate it)

Just wanted to add my voice that I have run into this in updating my 1.9.12+ site to 2.1. I am going to start the upgrade over again and more carefully document the steps I have taken in attempting to debug it.

I can say that it seems to be a mismatch with what version of mod_resource we had, and what steps the code has taken to prepare for the upgrade. It does not seem that resource_old was properly prepared, with the data copied over from resource.

If anyone is actively working on this one, please let me know what I can do to help, otherwise I will back up, start my upgrade again and add some more info to this thread.

A.J. Colianni
added a comment - 09/Aug/11 12:42 AM Just wanted to add my voice that I have run into this in updating my 1.9.12+ site to 2.1. I am going to start the upgrade over again and more carefully document the steps I have taken in attempting to debug it.
I can say that it seems to be a mismatch with what version of mod_resource we had, and what steps the code has taken to prepare for the upgrade. It does not seem that resource_old was properly prepared, with the data copied over from resource.
If anyone is actively working on this one, please let me know what I can do to help, otherwise I will back up, start my upgrade again and add some more info to this thread.

I was upgrading a site from 1.9.5 to 2.1 today and ran into this error. After a little digging I found that in the mod/resource/db/upgradelib.php the upgrade process is trying to create a new table resource_old and copying a lot from the resource table into it, and that query has a problem (at least for my install) it tries to copy a field summary from resource table into an intro field in resource_old except when I looked into the db I found there is no summary field but an intro field in the resource table. So, I updated the sql statement at line 253-256 and changed the r.summary to r.intro and the upgrade process went past this point without error.

Carl Heath
added a comment - 25/Aug/11 4:49 AM I was upgrading a site from 1.9.5 to 2.1 today and ran into this error. After a little digging I found that in the mod/resource/db/upgradelib.php the upgrade process is trying to create a new table resource_old and copying a lot from the resource table into it, and that query has a problem (at least for my install) it tries to copy a field summary from resource table into an intro field in resource_old except when I looked into the db I found there is no summary field but an intro field in the resource table. So, I updated the sql statement at line 253-256 and changed the r.summary to r.intro and the upgrade process went past this point without error.

I'm persistently getting the same error as A.J.
I'm trying a test upgrade from 1.9.13 to 2.1
I finally got an upgrade to work using a combination of Carl's fix and hunting the duplicate resources by repeatedly running

Re the duplicate ID. We are finding this while prepping to upgrade a 1.9.13 to 2.1. Our installation started as 1.7.something ages ago. We attempted a group by and that relieved the duplicate key issue but it resulted in missing resources (as we anticipated). We are now trying the suggestion to remove the unique key mentioned in the other ticket but I anticipate this being an issue further down the script because Moodle will eventually count rows between resource_old and resource. When it compares, if they are off it aborts... but I may tackle that problem later.

The honest solution here - and what we will probably have to do eventually - is to create a script that cleans up the duplicates in course_modules that are breaking the 1:1 relationship with resource. This will have to be a standalone script fired prior to upgrade.

Glenn Ansley
added a comment - 04/Nov/11 4:31 AM Re the duplicate ID. We are finding this while prepping to upgrade a 1.9.13 to 2.1. Our installation started as 1.7.something ages ago. We attempted a group by and that relieved the duplicate key issue but it resulted in missing resources (as we anticipated). We are now trying the suggestion to remove the unique key mentioned in the other ticket but I anticipate this being an issue further down the script because Moodle will eventually count rows between resource_old and resource. When it compares, if they are off it aborts... but I may tackle that problem later.
The honest solution here - and what we will probably have to do eventually - is to create a script that cleans up the duplicates in course_modules that are breaking the 1:1 relationship with resource. This will have to be a standalone script fired prior to upgrade.

Most of the 'mod_resource to 2009062600' errors are caused by the first few steps in /mod/resource/db/upgrade.php, where the mod_resource table structure is altered and then copied into mod_resource_old.

Even if you fix these, there have already been changes to the mod_resource table, so 'Continue'ing the upgrade procedure and re-running the mod_resource upgrade almost always fails again, because:

mdl_resource_old already exists;

mdl_resource.summary has been renamed to mdl_resource.intro;

mdl_resource.introformat column already exists;
You can easily fix these by dropping and renaming the appropriate columns, and then altering the version number in mdl_modules, for the 'resource' module. This should re-run the mdl_resource procedure from scratch.

I'm not a great PHP programmer, but it would be great if the upgrade.php performed some more tests before moving on. The 'are the number of records in mdl_resource and mdl_resource_old the same?' test often happens way after the actual error has taken place, and is quite undescriptive.

Ben Steeples
added a comment - 06/Mar/12 8:40 PM We've made some progress on this...
Most of the 'mod_resource to 2009062600' errors are caused by the first few steps in /mod/resource/db/upgrade.php, where the mod_resource table structure is altered and then copied into mod_resource_old.
Things to watch out for:
NULL values in mdl_resource fields (intro, alltext, reference);
Duplicate values in mdl_course_modules (in our example, for module=13, fixed by Bruno's suggestion);
MSSQL having row length errors in mdl_resource when dropping and adding fields (see http://stackoverflow.com/questions/2139365/cannot-create-a-row-of-size-8074-which-is-greater-than-the-allowable-maximum-row );
Even if you fix these, there have already been changes to the mod_resource table, so 'Continue'ing the upgrade procedure and re-running the mod_resource upgrade almost always fails again, because:
mdl_resource_old already exists;
mdl_resource.summary has been renamed to mdl_resource.intro;
mdl_resource.introformat column already exists;
You can easily fix these by dropping and renaming the appropriate columns, and then altering the version number in mdl_modules, for the 'resource' module. This should re-run the mdl_resource procedure from scratch.
I'm not a great PHP programmer, but it would be great if the upgrade.php performed some more tests before moving on. The 'are the number of records in mdl_resource and mdl_resource_old the same?' test often happens way after the actual error has taken place, and is quite undescriptive.

I'm upgrading from 1.9.16 to 2.2 and have the exact same error. Also encountered similar errors previous to this as others have re: duplicates, mdl_resource_old, etc. trying to work through each one as it comes up ... we also started with early db version 1.5 or 1.6.

Susan Mangan
added a comment - 03/Apr/12 5:26 AM I'm upgrading from 1.9.16 to 2.2 and have the exact same error. Also encountered similar errors previous to this as others have re: duplicates, mdl_resource_old, etc. trying to work through each one as it comes up ... we also started with early db version 1.5 or 1.6.

Petras Virzintas
added a comment - 15/May/12 10:29 AM I have the same error upgrading from 1.9.13 to 2.2.
I have successfully upgraded one database but the second one has this "brick wall" problem.
Rgds
Petras

Jean-Francois Belisle
added a comment - 19/Feb/13 3:01 PM I had the same problem and finally resolve it !!
First, after having this error message, you'll need to revert the following tables:
mdl_resource
mdl_course_modules
And change back de value of the resource module in the mdl_modules table.
I have run the following query:
SELECT r.id, r.course, r.name, r.type, r.reference, r.summary, 0, r.alltext, r.popup, r.options, r.timemodified, cm.id
FROM mdl_resource r
LEFT JOIN mdl_course_modules cm
ON r.id = cm.instance
WHERE cm.id is null
and deleted the corresponding records in the mdl_course_modules tables
Make sure you don't have any NULL in mdl_resource (intro, alltext, reference).
And restart the upgrade !
Good luck

Thanks, I suppose the solution would be as described right above - find resource records without matching course_modules entry. I suppose either somebody deleted the record by hacking DB directly or there was some problem in older Moodle 1.x

Petr Skoda
added a comment - 04/Jun/13 6:48 AM Thanks, I suppose the solution would be as described right above - find resource records without matching course_modules entry. I suppose either somebody deleted the record by hacking DB directly or there was some problem in older Moodle 1.x

Petr Skoda
added a comment - 05/Jun/13 9:29 AM Hello,
my patch should undo the resource hard-linking hacks some people used in 1.x. It should resolve some other inconsistencies too.
Thanks for the report and feedback here.
Petr

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Dan Poltawski
added a comment - 06/Jun/13 1:21 PM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

Dan Poltawski
added a comment - 10/Jun/13 2:35 AM Hi Petr,
I think the testing instructions need to be a bit more thorough on this, I was trying to improve them myself, but then I realised I didn't really know what I was asking for.
Can I ask you to be more explicit in the testing instructions about:
Creating a number of resources to test both this fix and that it doesn't introduce a regression
Exactly what db fields to manipulate