error occurred when doing backup

  function _keys_to_lower($array) {
    $new_array = array();

    foreach ($array as $key => $value){
      $new_array[strtolower($key)] = $value;
    }

    return $new_array;
  }

  /**
   * Get a list of tables in the db.
   */
  function _get_tables() {
    $out = array();
    // get auto_increment values and names of all tables
    $tables = $this->query("SHOW TABLE STATUS", array(), array('fetch' => PDO::FETCH_ASSOC));
    foreach ($tables as $table) {
      // make sure keys are lowercase
      $table = $this->_keys_to_lower($table);
      $out[$table['name']] = $table;
    }
    return $out;
  }

  /**
   * Get the sql for the structure of the given table.
   */
  function _get_table_structure_sql($table) {
    $out = "";
    $result = $this->query("SHOW CREATE TABLE `". $table['name'] ."`", array(), array('fetch' => PDO::FETCH_ASSOC));
    foreach ($result as $create) {
      $create = $this->_keys_to_lower($create);
      $out .= "DROP TABLE IF EXISTS `". $table['name'] ."`;\n";
      // Remove newlines and convert " to ` because PDO seems to convert those for some reason.
      $out .= strtr($create['create table'], array("\n" => ' ', '"' => '`'));
      if ($table['auto_increment']) {
        $out .= " AUTO_INCREMENT=". $table['auto_increment'];
      }
      $out .= ";\n";
    }
    return $out;
  }

I added this code in to sort this error. Something to do with a newer version on mysql.

This sounds a lot like a problem that was fixed last year. Can you confirm this is still happening in the latest code?

I am experiencing this error with 7.x-2.7

I also have CiviCRM installed, and have had some problems restoring too, and it makes me wonder if this could be related. So I am mentioning it here.

The problems I had with restored were resolved with this workaround: http://drupal.org/node/1542274#comment-6843466

Same issue here.

Notice: Undefined index: create table in backup_migrate_destination_db_mysql->_get_table_structure_sql() (line 295 of /sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

Using dev version now but not helping. I've also tried using the databased backed up but I got errors on the import.

Any ideas?

I'm using MySQL version 5.1.69 and PHP 5.3.25

Thanks in advance. I've tried also uninstalling and installing module again.

Line 295 refers to:

// Remove newlines and convert " to ` because PDO seems to convert those for some reason.
$out .= strtr($create['create table'], array("\n" => ' ', '"' => '`'));

Cheers

UPDATE: I've also tried changing the code to use the code above but still get same error but on a different line:

Notice: Undefined index: create table in backup_migrate_destination_db_mysql->_get_table_structure_sql() (line 302 of sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

Chiming in again as I've run up this again. Again with CiviCRM and Drupal.

The problem this time seems to be the SQL VIEWS that CiviCRM creates are not recognised as views by backup_migrate.

So I created a custom migration and set it to ignore the following views (which are listed as tables in the UI):

civicrm_view_case_activity_recent
civicrm_view_case_activity_upcoming

Am I "allowed" to re-open this ticket? Is there interest in this module being made compatible with CiviCRM? I seem to have some energy to look at it.

I'm having the same issue but on drupal installs with Webform mySQL views databases, I don't have CiviCRM.

Sharon

Hey Sharon,

Without looking into it my feeling is that the error might be being caused by the same problem facing CiviCRM, which is the modules inability to understand the difference between a SQL table and an SQL view.

My suggestion is to go into the advanced setting and exclude any of the webform views that you have created from the backup.

nzcodarnoc - You are correct, No error if I don't try to backup those tables. Now I just have to hope that I never need to restore them :(

Sharon

Hey there,

Note, it can be a bit tricky talking about SQL views in a Drupal context, because of the confusion with the "Views module". In this reply I am only making reference to SQL views.

It shouldn't be a problem. SQL views don't contain any data, they are more like a stored query. So if you need to restore you site the definition of those views is likely to be stored along with the webform views module. Worst case you'd have to recreate those views through the modules UI. But all the webform data would be safe.

Here's some more reading about SQL views: http://www.w3schools.com/sql/sql_view.asp