The most troublesome bit of code when it comes to migrating a Dokeos 1.6.x portal to a Dokeos 1.8.x version, is without doubt the learning paths bit, represented by the main/install/update-db-scorm-1.6.x-1.8.0.inc.php script.
The fact that it may look like the script is wrong sometimes (because it fails and leaves your database in a somewhat broken state), the problem actually comes down to the original database's integrity.
For example, you might get an error saying this:
SQL error in file /var/www/dokeos/main/install/update-db-scorm-1.6.x-1.8.0.inc.php at line 604.Well, that means there something wrong in your database. I'm not pushing the fault on you, of course, this is probably down to the fact that Dokeos 1.6 failed somewhere when creating a new course. In this particular case (line 604), the error is triggered because the table "scormdocument" could not be found in the database currently under migration. The query fails because it is supposed to, indicating that there *is* an integrity problem in your database. Now how to debug all this? Well, very easily... first you'll have to locate a variable in this script called $loglevel (should be on line 23) and change its value from 0 to 2. Then you'll have to re-launch the upgrade process but first watch your Apache error log. If you don't know how to do this, the best way is probably to try and locate the Apache log first, and then open up a file editor. On Ubuntu Linux distributions, by default you should be able to do this:
sudo tail -f /var/log/apache2/error.logBecause you changed the value of $loglevel, you will now see the progress inside your log file, of which databases the migration process is going through, and finally you will realise which database is inconsistent as the migration process will just stop on it. Once you have checked where the table was missing, or where there was something wrong (possibly a complete course database or directory missing), you can possibly fix it (by adding the scormdocument table yourself) or decide to ignore it and all the subsequent errors of this type, by changing the migration code around line 604, switching api_sql_query() for a good old @mysql_query(). I realise there are some points left blank in this explanation, but explaining every little detail is not really something I fancy, considering if you need these details, then you are probably better off hiring someone who doesn't to do your migration. Yes, I can be hired ;-)