Moodle
  1. Moodle
  2. MDL-25811

Automated backup fails to work without any hint

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1
    • Fix Version/s: 2.0.4
    • Component/s: Backup
    • Labels:
      None
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      Requires DB manipulation and, optionally, hacking:

      • OPTIONAL (for quicker testing, required hacking): edit backup_cron_helper.class.php and change the "60 * 90" to "60 *3", so the semaphore cleaning will happen after 3 mins (instead of 90).
      • DB MANIPULATION: In the config_plugins table insert one record with values (plugin => backup, name => backup_auto_running, value => 1). This will simulate the semaphore.
      • Enable automated backups in admin->courses->automated backups
      • TEST: Run the CLI cron.php script, should show message about automated backups running.
      • TEST: Run the CLI automated_backups.php script, should show message about automated backups running.
      • Wait 1 minute and re-rerun the 2 TESTS above, they must continue showing running status.
      • TEST: Wait > 3 minutes and run the cli cron.php. The semaphore gets cleaned (with message) and automated backup happens. Ignore any other output.
      • TEST: Run the cli automated_backups.php script. The semaphore has been cleaned by the previous test so backups should happen. Ignore any other output.
      Show
      Requires DB manipulation and, optionally, hacking: OPTIONAL (for quicker testing, required hacking): edit backup_cron_helper.class.php and change the "60 * 90" to "60 *3", so the semaphore cleaning will happen after 3 mins (instead of 90). DB MANIPULATION: In the config_plugins table insert one record with values (plugin => backup, name => backup_auto_running, value => 1). This will simulate the semaphore. Enable automated backups in admin->courses->automated backups TEST: Run the CLI cron.php script, should show message about automated backups running. TEST: Run the CLI automated_backups.php script, should show message about automated backups running. Wait 1 minute and re-rerun the 2 TESTS above, they must continue showing running status. TEST: Wait > 3 minutes and run the cli cron.php. The semaphore gets cleaned (with message) and automated backup happens. Ignore any other output. TEST: Run the cli automated_backups.php script. The semaphore has been cleaned by the previous test so backups should happen. Ignore any other output.
    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-25811_master
    • Rank:
      15159

      Description

      Automated backups do not start at all. Changing backup_auto_hour in admins settings for automated backups will not result in any changes or activity. No mail about start or fail. No reaction at all!

        Issue Links

          Activity

          Hide
          Arnold Mühren added a comment -

          Are the following messages related to the above?

          Error message /admin/cron.php (via browser):
          Checking automated backup status...RUNNING
          automated backup are already running. Execution delayed

          Error message /admin/cli/automated_backups.php (via commandline):
          Checking automated backup status...RUNNING
          automated backups are already. If this script is being run by cron this constitues an error. You will need to increase the time between executions within cron.
          Automated cron backups completed correctly
          Cryptic last line because nothing happens

          Show
          Arnold Mühren added a comment - Are the following messages related to the above? Error message /admin/cron.php (via browser): Checking automated backup status...RUNNING automated backup are already running. Execution delayed Error message /admin/cli/automated_backups.php (via commandline): Checking automated backup status...RUNNING automated backups are already. If this script is being run by cron this constitues an error. You will need to increase the time between executions within cron. Automated cron backups completed correctly Cryptic last line because nothing happens
          Hide
          James Yale added a comment -

          Getting this issue too, I can force the backup to run if I change a return value in the get_automated_backup_state function in backup/util/helper/backup_cron_helper.class.php

          Haven't been able to track down how Moodle is determining if the backup is running yet, but the comment in the code is interesting - does the functionality exist yet?

          I've included the function with the modification to force the backup to run (after the backup started running for me I reverted the code).

          /**

          • Gets the state of the automated backup system.
            *
          • @global moodle_database $DB
          • @return int One of self::STATE_*
            */
            public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) {
            global $DB;

          $config = get_config('backup');
          $active = (int)$config->backup_auto_active;
          if ($active === self::AUTO_BACKUP_DISABLED || ($rundirective == self::RUN_ON_SCHEDULE && $active === self::AUTO_BACKUP_MANUAL))

          { return self::STATE_DISABLED; }

          else if (!empty($config->backup_auto_running))

          { // TODO: We should find some way of checking whether the automated // backup has infact finished. In 1.9 this was being done by checking // the log entries. # return self::STATE_RUNNING; return self::STATE_OK; }

          return self::STATE_OK;
          }

          Show
          James Yale added a comment - Getting this issue too, I can force the backup to run if I change a return value in the get_automated_backup_state function in backup/util/helper/backup_cron_helper.class.php Haven't been able to track down how Moodle is determining if the backup is running yet, but the comment in the code is interesting - does the functionality exist yet? I've included the function with the modification to force the backup to run (after the backup started running for me I reverted the code). /** Gets the state of the automated backup system. * @global moodle_database $DB @return int One of self::STATE_* */ public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) { global $DB; $config = get_config('backup'); $active = (int)$config->backup_auto_active; if ($active === self::AUTO_BACKUP_DISABLED || ($rundirective == self::RUN_ON_SCHEDULE && $active === self::AUTO_BACKUP_MANUAL)) { return self::STATE_DISABLED; } else if (!empty($config->backup_auto_running)) { // TODO: We should find some way of checking whether the automated // backup has infact finished. In 1.9 this was being done by checking // the log entries. # return self::STATE_RUNNING; return self::STATE_OK; } return self::STATE_OK; }
          Hide
          Emma Richardson added a comment -

          Ok - I am running in Linux and I have been trying and trying to get this to run. Here is my code - can you help me figure out what to change? - I have tried commenting out, setting mtrace('RUNNING') to OK, various other issues but to no avail - I have been testing using automated_backups.php in cli - I can see where the changes I make are effecting (e.g. If I change text, it changes, so know that I am in the right place) but just can't seem to get the backup to actually initialize:

          mtrace("Checking automated backup status",'...');
          $state = backup_cron_automated_helper::get_automated_backup_state($rundirective);
          if ($state === backup_cron_automated_helper::STATE_DISABLED)

          { mtrace('INACTIVE'); return $state; }

          else if ($state === backup_cron_automated_helper::STATE_RUNNING) {
          mtrace('RUNNING');
          if ($rundirective == self::RUN_IMMEDIATLY)

          { mtrace('automated backups are already. If this script is being run by cron this con$ }

          else

          { mtrace("automated backup are already running. Execution delayed"); }

          return $state;
          } else

          { mtrace('OK'); }

          backup_cron_automated_helper::set_state_running();

          Show
          Emma Richardson added a comment - Ok - I am running in Linux and I have been trying and trying to get this to run. Here is my code - can you help me figure out what to change? - I have tried commenting out, setting mtrace('RUNNING') to OK, various other issues but to no avail - I have been testing using automated_backups.php in cli - I can see where the changes I make are effecting (e.g. If I change text, it changes, so know that I am in the right place) but just can't seem to get the backup to actually initialize: mtrace("Checking automated backup status",'...'); $state = backup_cron_automated_helper::get_automated_backup_state($rundirective); if ($state === backup_cron_automated_helper::STATE_DISABLED) { mtrace('INACTIVE'); return $state; } else if ($state === backup_cron_automated_helper::STATE_RUNNING) { mtrace('RUNNING'); if ($rundirective == self::RUN_IMMEDIATLY) { mtrace('automated backups are already. If this script is being run by cron this con$ } else { mtrace("automated backup are already running. Execution delayed"); } return $state; } else { mtrace('OK'); } backup_cron_automated_helper::set_state_running();
          Hide
          Daniel Pospisil added a comment -

          I have the same problem, cron is showing this:
          Checking automated backup status...RUNNING
          automated backup are already running. Execution delayed

          But backup hasn't been running for over a month...

          Show
          Daniel Pospisil added a comment - I have the same problem, cron is showing this: Checking automated backup status...RUNNING automated backup are already running. Execution delayed But backup hasn't been running for over a month...
          Hide
          Daniel M. Zimmerman added a comment -

          I have found that if I force backups to run once (as in James Yale's comment) and change the code back afterwards, then if they don't get unexpectedly interrupted on a subsequent run (by, for example, running out of disk space - see #MDL-25863) they continue to work.

          Obviously not a real solution - the key lies in the comment about "we should find some way of determining if the backup is in fact finished" - yes, and that should have been designed in in the first place. What it's doing to see that the backup is still running is looking at the value recorded in the database that says "this is running now".

          Show
          Daniel M. Zimmerman added a comment - I have found that if I force backups to run once (as in James Yale's comment) and change the code back afterwards, then if they don't get unexpectedly interrupted on a subsequent run (by, for example, running out of disk space - see # MDL-25863 ) they continue to work. Obviously not a real solution - the key lies in the comment about "we should find some way of determining if the backup is in fact finished" - yes, and that should have been designed in in the first place. What it's doing to see that the backup is still running is looking at the value recorded in the database that says "this is running now".
          Hide
          Daniel Pospisil added a comment -

          In my case the whole backup system doesn't work - even when i try manually backup a course it displays an empty page...
          So I tried to edit the backup_cron_helper.class.php file as mentioned above. It wasn't wroking, so I edited the code to this:
          /**

          • Gets the state of the automated backup system.
            *
          • @global moodle_database $DB
          • @return int One of self::STATE_*
            */
            public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) { return self::STATE_OK; }

          then I ran cron.php and then I reverted back the change ... and everything is now working... strange issue.
          Maybe it's caused by a failed backup before migrating to 2.0 - I didn't get a backup confirmation email a week before migrating to 2.0

          Show
          Daniel Pospisil added a comment - In my case the whole backup system doesn't work - even when i try manually backup a course it displays an empty page... So I tried to edit the backup_cron_helper.class.php file as mentioned above. It wasn't wroking, so I edited the code to this: /** Gets the state of the automated backup system. * @global moodle_database $DB @return int One of self::STATE_* */ public static function get_automated_backup_state($rundirective = self::RUN_ON_SCHEDULE) { return self::STATE_OK; } then I ran cron.php and then I reverted back the change ... and everything is now working... strange issue. Maybe it's caused by a failed backup before migrating to 2.0 - I didn't get a backup confirmation email a week before migrating to 2.0
          Hide
          Emma Richardson added a comment -

          I am still struggling with the code. I don't know if maybe I have a newer version but I have tried changing out various lines and nothing works.
          This is how my code reads - I have tried replacing the run_automated_backup with your suggestion as well as get_automated_backup_state. I have tried commenting out various parts in an attempt to bypass the checking automated state altogether.
          I would really appreciate any help. I am just starting with php and while I am starting to understand the general layout of the code, I am really not ready to write it!!

          I have this running live and have had no backups in a month - if my teachers find out they will probably kill me!!

          /**

          • Runs the automated backups if required
            *
          • @global moodle_database $DB
            */
            public static function run_automated_backup($rundirective = self::RUN_ON_SCHEDULE) {
            global $CFG, $DB;

          $status = true;
          $emailpending = false;
          $now = time();

          mtrace("Checking automated backup status",'...');
          $state = backup_cron_automated_helper::get_automated_backup_state($rundirective);
          if ($state === backup_cron_automated_helper::STATE_DISABLED)

          { mtrace('INACTIVE'); return $state; }

          else if ($state === backup_cron_automated_helper::STATE_RUNNING) {
          mtrace('RUNNING');
          if ($rundirective == self::RUN_IMMEDIATLY)

          { mtrace('automated backups are already. If this script is being run by cron this cons$ }

          else

          { mtrace("automated backup are already running. Execution delayed"); }

          return $state;
          } else

          { mtrace('OK'); }

          backup_cron_automated_helper::set_state_running();

          Show
          Emma Richardson added a comment - I am still struggling with the code. I don't know if maybe I have a newer version but I have tried changing out various lines and nothing works. This is how my code reads - I have tried replacing the run_automated_backup with your suggestion as well as get_automated_backup_state. I have tried commenting out various parts in an attempt to bypass the checking automated state altogether. I would really appreciate any help. I am just starting with php and while I am starting to understand the general layout of the code, I am really not ready to write it!! I have this running live and have had no backups in a month - if my teachers find out they will probably kill me!! /** Runs the automated backups if required * @global moodle_database $DB */ public static function run_automated_backup($rundirective = self::RUN_ON_SCHEDULE) { global $CFG, $DB; $status = true; $emailpending = false; $now = time(); mtrace("Checking automated backup status",'...'); $state = backup_cron_automated_helper::get_automated_backup_state($rundirective); if ($state === backup_cron_automated_helper::STATE_DISABLED) { mtrace('INACTIVE'); return $state; } else if ($state === backup_cron_automated_helper::STATE_RUNNING) { mtrace('RUNNING'); if ($rundirective == self::RUN_IMMEDIATLY) { mtrace('automated backups are already. If this script is being run by cron this cons$ } else { mtrace("automated backup are already running. Execution delayed"); } return $state; } else { mtrace('OK'); } backup_cron_automated_helper::set_state_running();
          Hide
          Emma Richardson added a comment -

          The other thought is that it has to be now be pulling the State_Running from somewhere in the database, I am presuming. Is there not a way to go in to the database and just change the setting from Running to Ready to Backup?

          Show
          Emma Richardson added a comment - The other thought is that it has to be now be pulling the State_Running from somewhere in the database, I am presuming. Is there not a way to go in to the database and just change the setting from Running to Ready to Backup?
          Hide
          Luca Mazzola added a comment -

          We had the same problem and we solved it with a workaround, after a little of code exploration for understanding its behaviour.
          We removed the entry in the table mdl_config_plugins (where 'mdl_' is the table prefix for our installation). The query is something like:
          delete from mdl_config_plugins where name like "backup_auto_running"
          Even if the state is not fully coherent (in other tables there are the entries for the backups of single courses with state unfinished or uncorrect), after that operation the backup procedure should restart to work (almost this is our experience)...

          The code that determines if the backup is running already states that this is an unreliable way of determining if there is a running instance, by the way
          HTH.

          Show
          Luca Mazzola added a comment - We had the same problem and we solved it with a workaround, after a little of code exploration for understanding its behaviour. We removed the entry in the table mdl_config_plugins (where 'mdl_' is the table prefix for our installation). The query is something like: delete from mdl_config_plugins where name like "backup_auto_running" Even if the state is not fully coherent (in other tables there are the entries for the backups of single courses with state unfinished or uncorrect), after that operation the backup procedure should restart to work (almost this is our experience)... The code that determines if the backup is running already states that this is an unreliable way of determining if there is a running instance, by the way HTH.
          Hide
          Emma Richardson added a comment -

          THANK YOU!!!! Running a backup right now! What a relief.

          Show
          Emma Richardson added a comment - THANK YOU!!!! Running a backup right now! What a relief.
          Hide
          James Yale added a comment -

          This worked for me to, here are the queries used for easier reference of anyone finding the bug:

          SELECT * FROM `<database_name>`.`mdl_config_plugins` WHERE `name` LIKE 'backup_auto_running'

          Then rather than removing the row I set the value back to 0:

          UPDATE `<database_name>`.`mdl_config_plugins` SET `value` = '0' WHERE `mdl_config_plugins`.`name` = 'backup_auto_running' LIMIT 1;

          Yet to determine if this fixes the backup yet though, last time I changed it the backup started running again but the value of this field still seemed to not get reset after the backup completed.

          Show
          James Yale added a comment - This worked for me to, here are the queries used for easier reference of anyone finding the bug: SELECT * FROM `<database_name>`.`mdl_config_plugins` WHERE `name` LIKE 'backup_auto_running' Then rather than removing the row I set the value back to 0: UPDATE `<database_name>`.`mdl_config_plugins` SET `value` = '0' WHERE `mdl_config_plugins`.`name` = 'backup_auto_running' LIMIT 1; Yet to determine if this fixes the backup yet though, last time I changed it the backup started running again but the value of this field still seemed to not get reset after the backup completed.
          Hide
          Mark J. Hughes added a comment -

          Yeah – this is a definite bug...and the worst part is that if you're not paying attention to your backups, you're not going to notice until you have a problem, and then it will be too late.

          Show
          Mark J. Hughes added a comment - Yeah – this is a definite bug...and the worst part is that if you're not paying attention to your backups, you're not going to notice until you have a problem, and then it will be too late.
          Hide
          Emma Richardson added a comment -

          I have one course that keeps hanging and sending this deal back to the auto backup running consistently. Is there anyway to exclude a course from the automated backup?

          Show
          Emma Richardson added a comment - I have one course that keeps hanging and sending this deal back to the auto backup running consistently. Is there anyway to exclude a course from the automated backup?
          Hide
          Mark J. Hughes added a comment -

          For those of you who don't want to play around with your database. You can work around the problem by adding

          set_config('backup_auto_running', '0', 'backup'); after line 243 (Which is //Everything is finished stop backup_auto_running) to the file backup/util/helper/backup_cron_helper.class.php

          Show
          Mark J. Hughes added a comment - For those of you who don't want to play around with your database. You can work around the problem by adding set_config('backup_auto_running', '0', 'backup'); after line 243 (Which is //Everything is finished stop backup_auto_running) to the file backup/util/helper/backup_cron_helper.class.php
          Hide
          Mark J. Hughes added a comment -

          Sorry, something hit me today and I went back and checked my notes and while I initially added it after line 243, that didn't work and I moved that line to 74 (along with a few other places, but I left it there, which was bad). I hope I didn't cause anyone too much grief.
          To be clear though – this isn't a fix – it is just a workaround for those of you who don't want to mess with your DB. It just resets the flag in the MySQL database that will then allow the backups to run. Do this on a large site, and you'll get lots of simultaneous processes running with unrestricted resource use – you'll likely crash your server if a site backup takes much longer than your cron interval. In short, I want to unpost my last post.
          Sorry!

          Show
          Mark J. Hughes added a comment - Sorry, something hit me today and I went back and checked my notes and while I initially added it after line 243, that didn't work and I moved that line to 74 (along with a few other places, but I left it there, which was bad). I hope I didn't cause anyone too much grief. To be clear though – this isn't a fix – it is just a workaround for those of you who don't want to mess with your DB. It just resets the flag in the MySQL database that will then allow the backups to run. Do this on a large site, and you'll get lots of simultaneous processes running with unrestricted resource use – you'll likely crash your server if a site backup takes much longer than your cron interval. In short, I want to unpost my last post. Sorry!
          Hide
          Emma Richardson added a comment -

          So where exactly is the best place to put the line - Line 74? My line 74 is

          if ($state === backup_cron_automated_helper::STATE_DISABLED) {
          mtrace('INACTIVE');

          Is that right? I would think we would either want to set that at the end of the backup (which might be an issue if the backup does not complete properly) or at the beginning.

          Show
          Emma Richardson added a comment - So where exactly is the best place to put the line - Line 74? My line 74 is if ($state === backup_cron_automated_helper::STATE_DISABLED) { mtrace('INACTIVE'); Is that right? I would think we would either want to set that at the end of the backup (which might be an issue if the backup does not complete properly) or at the beginning.
          Hide
          Emma Richardson added a comment -

          I ended up adding this line right before the file checks the auto backup status and it works like a charm - thanks.

          Show
          Emma Richardson added a comment - I ended up adding this line right before the file checks the auto backup status and it works like a charm - thanks.
          Hide
          Stefan Eberhard added a comment -

          Previous workaround!
          Where exactly to place what?

          Show
          Stefan Eberhard added a comment - Previous workaround! Where exactly to place what?
          Hide
          Emma Richardson added a comment -

          backup/util/helper/backup_cron_helper.class.php is the file to be adjusted.

          I placed the line
          set_config('backup_auto_running', '0', 'backup');
          Immediately before the line

          trace("Checking automated backup status",'...');

          That worked for me.

          Show
          Emma Richardson added a comment - backup/util/helper/backup_cron_helper.class.php is the file to be adjusted. I placed the line set_config('backup_auto_running', '0', 'backup'); Immediately before the line trace("Checking automated backup status",'...'); That worked for me.
          Hide
          James Cracknell added a comment -

          Have had the same problem myself. I believe it was caused by 3 massive scorm courses being uploaded! 100MB +

          Show
          James Cracknell added a comment - Have had the same problem myself. I believe it was caused by 3 massive scorm courses being uploaded! 100MB +
          Hide
          Paul Vaughan added a comment -

          @Luca Mazzola @James Yale, thank you very much indeed. I discovered this morning while attempting to move the backups to another server, that there weren't any, and I couldn't get them to run either. :o Your help has allowed me to start the backup process (now to wait ~36 hours to see if it completes!).

          Show
          Paul Vaughan added a comment - @Luca Mazzola @James Yale, thank you very much indeed. I discovered this morning while attempting to move the backups to another server, that there weren't any, and I couldn't get them to run either. :o Your help has allowed me to start the backup process (now to wait ~36 hours to see if it completes!).
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ho,

          the backup_auto_running is one semaphore (in DB) that we use to prevent multiple simultaneous executions of the automated backups.

          Under Moodle 1.9 we used to look for automated backup activity by looking to the backup logs table and, if no activity was found in XX minutes, it was assumed that the process had ended with error and the semaphore was cleaned to allow next executions to work.

          But that check os recent activity is something that we lost in the move to Moodle 2.0 so, once one automated backup execution failed, the semaphore was never cleared, leading to the situations reported here.

          What we have done is to (re-introduce) the check again, by looking for activity in the backup_controllers table, so, if no activity is detected in 90 mins, the semaphore will be cleaned and new automated backup executions will be allowed.

          Hope it helps, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Ho, the backup_auto_running is one semaphore (in DB) that we use to prevent multiple simultaneous executions of the automated backups. Under Moodle 1.9 we used to look for automated backup activity by looking to the backup logs table and, if no activity was found in XX minutes, it was assumed that the process had ended with error and the semaphore was cleaned to allow next executions to work. But that check os recent activity is something that we lost in the move to Moodle 2.0 so, once one automated backup execution failed, the semaphore was never cleared, leading to the situations reported here. What we have done is to (re-introduce) the check again, by looking for activity in the backup_controllers table, so, if no activity is detected in 90 mins, the semaphore will be cleaned and new automated backup executions will be allowed. Hope it helps, ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          (oops, edited branches, previous ones were incorrect)

          Show
          Eloy Lafuente (stronk7) added a comment - (oops, edited branches, previous ones were incorrect)
          Hide
          Gregor McNish added a comment -

          Not sure if this is the right place, but our auto backup fails when it hits a course containing a scorm object, and of course the flag in the db isn't reset, so it doesn't try again, as discussed above.

          I've traced a cause of this failure (at least on IIS/MSSQL, running ms native driver) to backup_structure_dbops_class,
          public static function move_annotations_to_final($backupid, $itemname)

          for some reason, when it hits
          $DB->set_field('backup_ids_temp', 'itemname', $itemname . 'final', array('id' => $annotation->id));

          the query it sends
          "UPDATE #mdl_backup_ids_temp SET itemname = N'filefinal' WHERE id = '3'"

          doesn't return, doesn't complete, doesn't error. Eventually the process gets killed by the web server.

          I did find that adding a timeout to the database do_query function in sqlsrv_native_moodle_database
          $result = sqlsrv_query($this->sqlsrv, $sql,array(),array('QueryTimeout'=>5));

          at least returns an error. rather than just hanging indefinitely.

          Show
          Gregor McNish added a comment - Not sure if this is the right place, but our auto backup fails when it hits a course containing a scorm object, and of course the flag in the db isn't reset, so it doesn't try again, as discussed above. I've traced a cause of this failure (at least on IIS/MSSQL, running ms native driver) to backup_structure_dbops_class, public static function move_annotations_to_final($backupid, $itemname) for some reason, when it hits $DB->set_field('backup_ids_temp', 'itemname', $itemname . 'final', array('id' => $annotation->id)); the query it sends "UPDATE #mdl_backup_ids_temp SET itemname = N'filefinal' WHERE id = '3'" doesn't return, doesn't complete, doesn't error. Eventually the process gets killed by the web server. I did find that adding a timeout to the database do_query function in sqlsrv_native_moodle_database $result = sqlsrv_query($this->sqlsrv, $sql,array(),array('QueryTimeout'=>5)); at least returns an error. rather than just hanging indefinitely.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi Gregor, can I suggest you creating a new issue for that problem? Please report as much info as possible (versions, how to reproduce it...). Initially I'd recommend you to update to latest Moodle 2.0.x+ release, because it some changes have happened in our impl. of the native sqlsrv driver (not sure if related or no, perhaps you could also try to run all the DB unit tests in your server to see if they detect something).

          In any case, let's discuss that in another issue, plz and tia!

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Hi Gregor, can I suggest you creating a new issue for that problem? Please report as much info as possible (versions, how to reproduce it...). Initially I'd recommend you to update to latest Moodle 2.0.x+ release, because it some changes have happened in our impl. of the native sqlsrv driver (not sure if related or no, perhaps you could also try to run all the DB unit tests in your server to see if they detect something). In any case, let's discuss that in another issue, plz and tia! Ciao
          Hide
          Sam Hemelryk added a comment -

          Thanks Eloy integrated now

          Show
          Sam Hemelryk added a comment - Thanks Eloy integrated now
          Hide
          Rajesh Taneja added a comment -

          Works Great
          Thanks for providing the fix, Eloy.

          Show
          Rajesh Taneja added a comment - Works Great Thanks for providing the fix, Eloy.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          All git & cvs servers have been updated with these cool changes, so closing, many thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - All git & cvs servers have been updated with these cool changes, so closing, many thanks!
          Hide
          Stefan Eberhard added a comment -

          Thanks to all working on this issue!

          Show
          Stefan Eberhard added a comment - Thanks to all working on this issue!
          Hide
          Gregor McNish added a comment -

          Thanks Eloy, I've updated to the latest Moodle, the issue has changed . Will post a tracker entry once I've figured out what I can.

          Show
          Gregor McNish added a comment - Thanks Eloy, I've updated to the latest Moodle, the issue has changed . Will post a tracker entry once I've figured out what I can.
          Hide
          James Yale added a comment - - edited

          This is marked as closed but I'm setting seeing the issue on a recently upgraded Moodle 2.2.1+ where the backup_auto_running flag isn't being cleared on the database after a backup run - is there another bug related to it?

          edit: Nevermind, it's fixed itself, can't find a way to delete this comment!

          Show
          James Yale added a comment - - edited This is marked as closed but I'm setting seeing the issue on a recently upgraded Moodle 2.2.1+ where the backup_auto_running flag isn't being cleared on the database after a backup run - is there another bug related to it? edit: Nevermind, it's fixed itself, can't find a way to delete this comment!

            People

            • Votes:
              18 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: