Acording to MySQL Reference Manual (http://dev.mysql.com/doc/refman/5.0/en/charset-table.html and http://dev.mysql.com/doc/refman/5.0/en/charset-column.html) a slight change on Samuels code will also change column collation:

<?php
    $db = mysql_connect('localhost','iccamoes_iuser','m234icamoes');

    if(!$db) echo "Cannot connect to the database - incorrect details";

    mysql_select_db('iccamoes_intramoodle'); $result=mysql_query('show tables');

    while($tables = mysql_fetch_array($result)) {

        foreach ($tables as $key => $value) {

            mysql_query("ALTER TABLE $value CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci");

        }

    }

    echo "The collation of your database has been successfully changed!";

?>

This way, all column fields will have COLLATE utf8_unicode_ci appended. I really don't know if that's necessary.

Hi, Thanks for your reply Paul.

Yes, we have developed a module called assess where user can upload answers for the given question and he can also upload a file (images or document file). In moodle 1.9 those files were stored in moodledata folder. Now we upgraded to moodle2.2, during upgradation the older files are now stored in filedir folder and those values also updated in database (mdl_files table). I'm trying to access the user uploaded older files using pluginfile.php but the files are not accessible. 

Yes, we turned on legacy files also. 

Kindly help me to resolve this problem.

Thanks in advance.

Shankar.

And I heared some people running into trouble by not upgrading to the latest 1.9 before upgrading to 2.2. 

So upgrade firtst to 1.9.19+ too.

Sure, thank you all- atleast I have confirmed the version steps in upgrading-  Now we need to upgrade our current Moodle version 1.9.15 to 2.3 but actually have no clue of how to go about it or where to to start from... Your success and steps would really help us.

Speaking from one paranoid organization to another, there are things you can do to back up what's there:

1. Moodle 2.3.x still has course backups and can still include user data.
2. Make sure you have a good backup of everything.
3. Do both.

What we decided to do is basically back up everything every night. Our Moodle is hosted offsite on Debian/MySQL. Internally, we are a Windows shop, so we have dislike systems involved. Here are the steps we take:

1. Schedule a nightly cron job to dump the Moodle database.
2. Schedule a nightly rsync job on-site to sync the database, Moodle public html files, and Moodle data files. Since we use rsync (the cygwin version), only changes are synchronized making the time it takes nightly bearable.
3. (Optional) Zip the database, html files and data together into a large archive snapshot.
4. Back up what you've synchronized using whatever you normally do for internal backup.

This way, you should basically be able to restore everything to the way it was on any particular day for as far back as you keep your backup sets. You should periodically test this by restoring a complete backup to a test location (see Moodle Migration for details). We do this three times per year in between terms. It's work, but that's how you insure you CAN restore in the event of a real disaster.

This should work regardless of whether you run Moodle 1.9, 2.3 or 2.4. 

As far as the upgrade issues, as with any CMS, plugins can always be the sticking point. About the only advice I have is to try to pick ones that seem to keep up.

Tammy, some random thoughts, have you considered this as an option:

1. Create new 2.4
2. Backup and restore courses from your old Moodle

Here it gets a bit tricky:

Plugins.  Whatever way you upgrade/migrate, yoou'll probably have plugin problems.  It all depends.  We have been caught by loss of functionality in 1.9 > 2.4, and in other ways, helped by it.  Also, some plugins we had in 1.9 have been replaced by built in capacities.  It's the 1.9 plugins you see as indispensible and are NOT ready for 2.4 where you will have the problem.  SO: make sure you can specify exactly what you want and you may be able to get it in another way.  Maybe.

Shifting members.  In one site I did this:

1. E-mailed members in the old Moodle saying who needs to shift over, and I created accounts with a spreadsheet.  
2. Latecomers just created their own accounts manually.

I found a LOT of spam accounts.

How you go partly depends on

• the number and complexity of the courses
• the dependency you have on the plugins, and a LOT of plugins have gone west in the shift from 1.9 > 2.0
• if you can do this in slow motion?  Run 2 sites for a while?

On the other hand, to be reassuring: I do not believe we will ever have a fraught upgrade like the 1.9.x > 2.x again.  Also the plugin future is likely to be better, with upgrade from the admin interface coming.

The question: which of the possible hard and difficult routes to take.  The advantage of the backup/restore is a cleaner leaner database.  Probably.

and also: this is a belief statement - Moodle 2.4 is better in it's scorm handling.  You may like it.  No you are not being too paranoid.

Good luck.

-Derek

Hello Guillermo, 

Thank you for replying.  I am at home now and it is 22:53.  I left work hours ago but this is so critical that I have logged in here to see whether there is any more information.

I am upgrading from 1.9 to 2.2 then 2.7.  I am not sure how many different versions there were before 1.9.

There are 20000 users, though many of them are inactive.  I think the situation IS similar.  

In 1.9 creating a filter and listing users does not produce an option to delete users.

I did read the pages for upgrading from 1.9 to 2.0 and 2.1 and 2.2

As far as I remember there is no mention of the timeout issue. I know it says the upgrade is complex and will take longer.  What is not mentioned is that in the process of upgrading the site may not complete the 1st script and that there will be not necessarily be a clear indication of what has happened.  

I may start a new thread about this but I don't have all the information to hand. I have made the changes suggested to php.ini and the library files but not the collation changes because our tables are all UTF_UNICODE_CI.

I am going to attempt the upgrade again on Monday morning.

Sorry but I still think that the either: the upgrade script itself should interrogate the config and database when it is going from 1.9 to 2.x and should alter parameters where it can internally but also if necessary halt the upgrade with a message to alter settings and try again; or, this pitfall should be made clearer.  But perhaps it is not very common.  

Of course there will be fewer and fewer 1.9 installations running as time goes on then it won't matter so much.  

I also want to repeat that moodle is, most of the time, a small part of my job, not because I want it that way but because I don't set my own priorities.  

regards, Paul.