Moodle

Hi, i've got the same issue but on the upgrade of the assignment module

I think I have a "solution" - or at least an explanation of the 'error' that I experienced above.

Early on in the upgrade process, there is the possibility of changing new settings. On clicking on the [save] button at the bottom of this settings page, I waited for almost 2 minutes and then got a "server timed out" error message. I then clicked on the [save] button again and got the following message:

Upgrade already running in this session, please wait!
Click on the exclamation marks to ignore this warning (!!!).
( Continue )

I clicked on the 'continue' link and then got the error message described above, i.e.: "Found more than one record in fetch() !"

Later on, I reverted back to my original 1.8.4 system, and again attempted the upgrade to 1.9. I again got the "server timed out" message, and again clicked on the [save] button at the bottom of the settings page. And again, I got the "Upgrade already running" message. However, this time, I did nothing, and noticed that although the page was not reloading, the status bar at the bottom of the browser page indicated that changes were being made to the server. After about 5 minutes, a new page appeared indicating the successful installation of some tables, and the upgrade continued without problem. The new system appears to be working as expected.

So, the 'solution' is NOT to click on either the 'exclamation marks' nor the 'Continue' links, but just wait.

Adding some people here. This seems to be related to the gradebook upgrade... if I'm not wrong.

IMO we should try to fix those problems (or provide a way to do so), instead of failing, but it's far from my knowledge to say if that's possible or no.

Please watchers, comment and feel free to assign this to you. TIA!

Since reporting on my apparent 'solution' to the above mentioned problem (Found more than one record in fetch() !), I have since discovered that teachers and students are unable to edit their profiles. And, bizarrely, teachers are able to turn editing on in their courses, but the add resource and activity menus are not visible.

Perhaps these issues may be related?

The details are explained here:
MDL-14159
and here
http://moodle.org/mod/forum/discuss.php?d=93977

I have since reverted back to 1.8.4, and then done a new upgrade, which I report here:

MDL-14159

the above mentioned error (Found more than one record in fetch() !) did not appear, but the browser did hang. Teachers are now able to add resources and activities to their courses, but users are NOT able to edit their profiles or change their passwords.

To enable editing profiles and passwords in 1.9. you must set $CFG->defaultuserroleid in Authenticated User (See MDL-14183), as well as allow corresponding capabilities for Authentificated user role. Capabilities allowed by default, but default role during upgrade is Guest, not Authenticated User.

This reported bug seems difficult to reproduce.

We encountered this bug today, while trying to upgrade from 1.8.3+ to 1.9.2+. We had tested the upgrade in a test serve that is a copy of the production server and the problem did not occur there, so we were unpleasantly surprised when the loop occured while upgrading the assignment module.

On posting a message in the Installation problems forum I discovered that this issue has existed at least since April. With the school year starting in a month, this is a rather urgent issue to us, but we have no idea as to the exact cause of the problem and therefore do not know what to do about it. I hope the new gradebook is not too complex for its own good.

Nick, can you analyse this closely?

The error is thrown in fetch_helper() in http://cvs.moodle.org/moodle/lib/grade/grade_object.php

Where the comment says: "we should not tolerate any errors here - problems might appear later"

It seems people do have some duplicates for some reason, so we need to find a way to recover and fix the problem, even if we only keep one $instance of the data (say).

Hi all,

I am relieved to say that we finally managed to overcome the problem with the "Found more than one record in fetch() !" error. It was a result of 9 duplicate rows in the mdl_grade_items table and 1 duplicate row in the mdl_grade_categories table. We found these by:

A: adding $CFG->debug=1; to the middle of the config.php file (this showed us where the duplicates in the grade items were in combination with the setting below)

B: setting debug to true in the mod/assignment/db/upgrade.php

We could then track down the duplicate rows in the moodle MySql database and delete the offending rows.

After that the upgrade was a breeze. So the solution to the problem would be some kind of command that removes these duplicate rows before the upgrade.

Thanks for the info Paul.

What I don't understand though, is that the tables you mention, grade_items and grade_categories, do not exist in 1.8. There is grade_item and grade_category though (notice the singular form). Are these the tables in which you found duplicates?

Hi Nicolas,

The error came to light after the database had been upgraded, so I found the duplicates in the mdl_grade_items table and the mdl_grade_categories table. I was not aware of the duplicates existing already in the 1.8 database, but they may have (as a result of a botched course restore for example). However, I would not know in which tables they would have occurred in that case.

I finally managed to reproduce this error. This happens when an upgrade is running on the server and a new browser window is opened to attempt the upgrade at the same time (or a similar condition). There is no actual bug in the gradebook code in this case. We are working on a way to prevent concurrent upgrade processes.

I can second Nicolas findings. The same error was thrown for me in the similar situation - another browser opened the upgrade process. I forgot to put the server into the maintenance mode. Maybe this would help?

> We are working on a way to prevent concurrent upgrade processes.

Can I help with this somehow? Has this been discussed somewhere online?

Nicolas/Petr, what was the last word on this? I thought I saw some code to prevent concurrent upgrades but I could be mistaken....

the full concurrent prevention is in HEAD only (and there still might be some pending problems there),

in 1.9.x we have only concurrent protection in current session - which means if somebody ignores the warning and closes browser and open it again the data gets corrupted; the easies solution for affected sites is to restore from db dump and rerun upgrade and let it finish even if the page/UI times out

There is a new code in HEAD that will prevent similar problems in the future, unfortunately the changes required were too big for 1.9.x, sorry

thanks for the report and cooperation

I can confirm that this issue occurs when more than one browser is open and users logged in after the initial upgrade but before the final.