I mark this as a support request because I've used BM in so many contexts and it has never failed and never had this problem, so I'm assuming that I've messed up something, but I have run out of ideas as to what it could be.

Backup and Migrate fails if I try to do a backup or if I try to edit a profile, apparently because it fails to retrieve any table names. If I'm in the profile edit screen, the select lists to select tables are empty and I get this error message 220 times:

Notice: Undefined index: name in backup_migrate_destination_db_mysql->_get_tables() (line 186 of /home/yosemite/public_html/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

and this error message two times

Notice: Undefined index: name in backup_migrate_destination_db_mysql->_get_table_names() (line 153 of /home/yosemite/public_html/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

Thus far I have

  • Disabled, uninstalled, re-enabled Backup and Migrate
  • Completely deleted the database and restored from several backups
  • Ran an extended check on the DB using mysqlcheck
  • Downloaded a new copy of the module
  • Ran cron, DB updates, flushed caches and all that

Now here's the crazy part - I have this site mirrored on another server and it has absolutely no problem like this.

At this point, I'm just looking for stupid things I may not have tried that might be causing this. Any bright ideas?

CommentFileSizeAuthor
#24 1558680.patch1.31 KBsoulston
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

1800collect’s picture

I am getting this error after upgrading to Drupal 7.14. I was fine and ran Backup and Migrate before upgrading. I tried running it afterwards and I'm getting the same error. :(

kslagboom’s picture

Same issue here. Had a new site running in 7.12 and all was good. With the security release May 2, I figured I'll update to 7.14 and carry on. After the update, Backup/Migrate failed with the 'Notice: Undefined Index ... line 186'. I haven't tried to debug this yet but will look into deeper if not solved soon.

A quick and dirty downgrade to Drupal 7.13 (drop the code overtop) is a temporary work around, allowing Backup/Migrate to work again.

silkogelman’s picture

backup_migrate-7.x-2.x-dev has the same problem after updating to Drupal core 7.14. (line numbers are different)

Messsage to user just says "Could not complete the backup.", log has all the notices mentioned by ergophobe.

and to confirm: Drupal core 7.13 does not have this issue.

NPC’s picture

Aha, sorry, I just raised a duplicate then, http://drupal.org/node/1558746, it can be deleted as I don't think it provides any more information :)

braindrift’s picture

Quick patch for mysql: insert $table = array_change_key_case($table); after line 185 in modules/backup_migrate/includes/destinations.db.mysql.inc

bacek’s picture

Same problem for me (after upgrade to 7.14 and quick patch doesn't help.

diempi’s picture

Same for me the quick patch didn't work

raveendrab’s picture

Hi,

Sorry, I have added a duplicate at http://drupal.org/node/1545308#comment-5949560.
The quick patch worked fine for me.

bvt’s picture

The quick patch fixed it for me after the update to Drupal 7.14.

Syd Barrett’s picture

The patch works for me.
Should it look like this?

 foreach ($tables as $table) {
      $table = array_change_key_case($table);
      $out[$table['name']] = $table;
    }

Do you suggest to use this patch or is better to downgrade to 7.13 and wait for a more stable version? It looks like there are a lot of problems with this version.

raveendrab’s picture

HI,

After completing the backup, it gives the following error.
Notice: Undefined index: create table in backup_migrate_destination_db_mysql->_get_table_structure_sql() (line 201 of /usr/local/share/drupal7/modules/backup_migrate/includes/destinations.db.mysql.inc).

Salasta’s picture

OK done patch everything working fine now

Syd Barrett’s picture

I've got the same problem
Notice: Undefined index: create table in backup_migrate_destination_db_mysql->_get_table_structure_sql() (line 201 of /sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

Bye bye version 7.14. I'm putting back my previous version

raveendrab’s picture

Hi,

The patch dumps only the INSERT statements.
It skipped all CREATE statements. Hence the dump is not useful.

Syd Barrett’s picture

URGENT!!!! Does the update make any changes on the folder "sites"?

payamspot’s picture

Same problem, after updating Drupal to 7.14

diempi’s picture

when I do a backup and set the settings to download it , it works fine but not when I set the backup to save it to my private folder, for the moment I keep the downloaded backup waiting on a fix for the destination folder one, thank you for the patch

LiveWire’s picture

subscribe

yustos’s picture

Quick patch for mysql: insert $create = array_change_key_case($create); after line 199 in modules/backup_migrate/includes/destinations.db.mysql.inc when you had apply patch #5

diempi’s picture

#19 works for me thank you

raveendrab’s picture

#19 works for me also.
Thanks for immediate fix.

korn3lius’s picture

#19 also works for me

Follow this step:
1. See comment #5 and insert the patch at line 185
2. See comment #19 and insert the patch at line 199

DrupalGideon’s picture

Is anyone going to create a proper patch file for this please so we can get it tested and committed?

Thanks

soulston’s picture

FileSize
1.31 KB

#22 also works for me. I created a quick patch for 7.x-2.2.

As an aside it looks like dev is taking a different approach here.

scottrouse’s picture

Category: support » bug

This really should probably be a bug report.

se7en76’s picture

Category: bug » support

Patch #5 worked for me after the D7.14 core upgrade aforesaid issue.
Thanks 'dendie' for the quick job !

mfarha’s picture

Category: support » bug

#5 and #19 worked for me. Thanks!

se7en76’s picture

Just the time to write a personal report that there is a patch file from 'souslton' including also the second line adding after line 199 (from 'yustos').
You guys are wonderful! Thanks again.

ronan’s picture

Patch committed to dev. If I can get some confirmation that the dev works, I'll push a new stable release today.

For the curious, this is the core issue that caused this: http://drupal.org/node/1171866

Thanks all

mherchel’s picture

Today's (5/3/2012) dev version is not working for me.

I uploaded the new module (overwrote the old), ran update.php.

When I do a quick backup, I still get the same errors:

Notice: Undefined index: name in backup_migrate_destination_db_mysql->_get_tables() (line 275 of /home/nfbanet/public_html/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).
Notice: Undefined index: name in backup_migrate_destination_db_mysql->_backup_db_to_file() (line 120 of /home/nfbanet/public_html/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).
Could not complete the backup.

PS. Thanks for being on top of this Ronan!

grasmash’s picture

@mherchel Don't forget that dev packages are only updated by Drupal.org twice a day. Looks like it has been updated from the repo yet. I'd suggest pulling directly from git if you'd like the most recent version.

mherchel’s picture

@Madmatter23- I checked the .info file to be 100% sure. It looks like i do have today's version:


name = Backup and Migrate
description = "Backup or migrate the Drupal Database quickly and without unnecessary data."
core = 7.x

files[] = backup_migrate.module
files[] = backup_migrate.install
files[] = includes/destinations.inc
files[] = includes/profiles.inc
files[] = includes/schedules.inc

configure = admin/config/system/backup_migrate
; Information added by drupal.org packaging script on 2012-05-03
version = "7.x-2.2+31-dev"
core = "7.x"
project = "backup_migrate"
datestamp = "1336003458"

Is it working for you?

pjbarry21’s picture

This worked for two of my sites (#22 -- using #5 and #19) that already had the module installed. But when I tried to install Backup and Migrate on a site that had never had it installed before, the latest dev version didn't work. I removed it and installed 7.2.2 and the patch and that worked.

watman’s picture

Also applied #24 to 7.x-2.2 and that cleared up the error for me. Thanks soulston.

dogbreath’s picture

FWIW, replacing 7.x-2.2 with 7.x-2.x-dev did not work for me. I then tried disabling and uninstalling BM, then re-installing the dev release. This also did not work.

ETA: just read #31. That's probably why this didn't work for me.

dogbreath’s picture

Checked out a fresh copy of 7.x-2.x with git and can confirm the patch is working. Thanks much, all.

jnettik’s picture

I can also confirm the fix in #22.

BrightBold’s picture

I tried this earlier today (the dev version hadn't been pulled from git yet so I used the patch) and I can confirm it solved the problem. Thanks!

xbrianx’s picture

I am also getting this issue after updating to 7.14

lilbebel’s picture

I am also getting this problem after updating today. Also, I have never used patches and have no idea what to do with one. I've read they can mess everything up if you don't know what you're doing. I am not a developer and come from a design background. Can someone please write an idiot proof step by step as to what to do with #19 patch?

Help!

Thanks.

sirmee2001’s picture

I also had the same issue after upgrading to 7.14. Solution #22 worked for me.

ronan’s picture

Status: Active » Fixed

This patch has been applied to the module so download the latest dev version and you should have the fix. Please confirm it works and doesn't cause any more problems and I'll get a stable release up.

R

lilbebel’s picture

Hello,

I added the patches #5 and #19 and they work. I tried installing the dev version and it didn't work I'm afraid.

M

cy08’s picture

#5 and #19 work perfectly, thank you guys!

dogbreath’s picture

@ronan I re-downloaded the most recent dev release about an hour ago (just after you posted #42) and it still didn't work. However, I think it may not have been refreshed from git. I have successfully used the most recent 7.x-2.x branch from git, so I believe the fix does work.

mermentau’s picture

I'm using the dev from about 2 hours ago and it's not working for me.

martinc’s picture

I applied #22, cleared caches

Now I get the this error about 200 times:

Notice: Undefined index: create table in backup_migrate_destination_db_mysql->_get_table_structure_sql() (line 201 of ..... \backup_migrate\includes\destinations.db.mysql.inc).

But the backup reports:

Default Database backed up successfully

I don't trust the backup, But ill restore it to test.

martinc’s picture

Status: Fixed » Active

Tested a restore ...No good..

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AUTO_INCREMENT=1' at line 1 in backup_migrate_destination_db_mysql->_restore_db_from_file() (line 133 of /home/idlproje/public_html/mbm/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

Ill try the dev version.

mermentau’s picture

OK! It works with the dev version. I may have downloaded the wrong one with Drush the first time.

martinc’s picture

Status: Active » Fixed

Yes dev version works!

braindrift’s picture

Hi guys,

my solution from #5 was ment as a quick and dirty solution. IMHO a proper solution would be to replace all read statements of the array containing the table information with the real key-names (first letter uppercase) or to use the option PDO::CASE_LOWER if possible.

braindrift’s picture

Status: Fixed » Needs review

After looking more than 5 min at the code:
I suggest to put $conn->setAttribute(PDO::ATTR_CASE, PDO::CASE_LOWER); after line 283 in modules/backup_migrate/includes/destinations.db.mysql.inc

maxplus’s picture

Hi,
installing de dev version of today works for me.

Thanks!

dr_dev’s picture

This may also be my problem: http://drupal.org/node/1560286

However, I have no new error log and no new Notice.

rileyhuff’s picture

Installed the dev and it works but now the backed up files have .gz.cpgz or simpley .gz compression. You can restore from BAM but not PhpMyadmin. I have been unable to open the file with the OSX archive utility or from the terminal.

I don't use the BAM restore in Dev because BAM does not drop database tables and I want to revert back completely clean sometimes so I reload, the last good database via an alternate method.

rmathew’s picture

#52 worked for me, thanks

ronan’s picture

Status: Needs review » Fixed

@dendie:

I agree that the solution that went in isn't ideal, but I'd considered the other two options and dismissed them for various reasons. Ideally I would use the proper keys (ie: Name). That's what I'm doing in the D5 and D6 version and worked fine for years before the powers that be decided that column name shall always be lowercase #337926: Force connection with PDO::CASE_LOWER and I had to change it for D7. Then those same powers decided that that previous decision was arbitrary and meaningless and so they arbitrarily reversed the decision #1171866: Enforced fetching of fields/columns in lowercase breaks third-party integration. They also felt it was important to backport this arbitrary change D7.

If I go back to using the natural case keys, I'll break the module with previous versions of D7, but if I add the PDO:CASE_LOWER back I reproduce an meaningless behavior just because it's what used to be done. Forcing case on the keys after the results have been pulled is a little hacky, but it protects us from further arbitrary changes at the DB layer and variations in mysql behavior. I don't love it but it's predictable.

I've had some confirmations that the dev fixes the issue, so I'm going to push out a stable release as-is so people get pinged with the update.

Thanks all for testing, patching, etc.

Xixi’s picture

#52 worked for me too, thanks

TJM’s picture

Upgrading to backup_migrate 7.x-2.3 solved the error for me.
TJM

rileyhuff’s picture

7.x-2.3 solved it.

payamspot’s picture

Backup and Migrate 7.x-2.3 solved it.

1800collect’s picture

Backup and Migrate 7.x-2.3 released on May the Fourth has fixed the issue of allowing download. I have not yet tried to restore from these backups. Anyone else have success with restoring from the backup?

akkn’s picture

Status: Fixed » Needs review

#5 and #19 worked for me.
But when I updated, to (Backup and Migrate7.x-2.3) then the backup that I took was not reliable.
I cannot import (restore it), to the database.

Tezza’s picture

I'm happy to be corrected, but I think the out-of-the-box default setting for Quick Backup is set to GZip in 2.3, whereas in previous versions you would have had to explicitly set this in Advanced Backup.

I'm running XAMPP on WinXP and it doesn't seem to like GZip. I can see that phpMyAdmin suggests it should but for now I've set and saved the default as Zip (or None). So, for me, the restore works just fine in 2.3 after dropping tables thru phpMyAdmin on my WinXP localhost.

I have no idea what's going on with your set-up akkn as your post is a bit light on detail, but this might help.

akkn’s picture

You are right Tezza, when I use “zip compress file” it’s OK on the XAMPP & WinXP and on my Hosting server.
But, I usally set the Gzip on (XAMPP & WinXP) and on my Hosting server without any problem on both and now seem to have problem on both.

GinaF’s picture

I just upgraded to Backup and Migrate 7.x-2.3, took a backup of my database and then restored the backup.
I made sure it used .zip.
All seems well.

ergophobe’s picture

Ha! I assumed this was a problem on my end. I should have looked a bit farther, but didn't notice my test and live versions were on different versions of core.

Anyway, 2.3 fixes my initial reported bug.

Not sure if #52 is still holding this as "needs review" but it's fixed for me.

lhugg’s picture

Confirming that upgrade to Drupal 7.14 causes the error to appear, and that BM 7x-2.3 upgrade fixes the issue. Works fine on both xampp and CentOS linux/Apache.

DigitalFrontiersMedia’s picture

Status: Needs review » Fixed

I confirm 2.3 fixes as well as have others I've talked to. Changing status to fixed.

possiBri’s picture

Patch worked for me, thank you! =]

gianfrasoft’s picture

#61 solved my issue without coding (the best way).

Thanks.

erok415’s picture

Status: Fixed » Needs work

I have updated to 7.14 and have issues with 7x-2.2. No tables are selectable within profile.

When I update to 7x-2.3 I could backup but restoring didn't work. For some reason a .info file is created along side the backup gzip file.

I was in the middle of creating a new site on D7.14 and tried using backupMigrate 7x-2.3 and the same issue is happening - .info file is created and when trying to restore, there is a MySQL error in phpmyadmin.

I have another site that I was updating all contribs first while backing up before every update. Everything was fine until I updated the D7.14 core. BTW, I was using b_m7x-2.3 during the entire update of contribs. Somehow D7.14 messes things up for b_m.

PS. I'm using the latest 7x-2.3 update from 4 May 2012.
E.

erok415’s picture

Update:
Since 7x-2.3 isn't working for me and I need something in place, I decided to go back to 7x-2.2 and apply #5 and #19 the 7x-2.2 version. That worked. I was able to backup and restore the database from phpmyadmin without any errors.

I look forward to these issues being fixed in 7x-2.4.
E.

PS. It's a great module!

mermentau’s picture

I confirm what erok415 said in #72. I tried a manual backup on a 7.12 site and the database file couldn't be loaded via phpmyadmin. It gave errors. The backup had been made with 7.x-2.3. I'm guessing a lot of folks that updated to the latest BM 7.x-2.3 are having automatic backups that are no good.

Tezza’s picture

@bumpaw
We could narrow that down to folks who were already using Gzip before upgrading and have not yet had need to restore a site.

I think Bzip2 provides better compression than Gzip, and is well-known to *nix geeks, while Zip is super-familiar to Windows users. Both of which work. I run small sites so didn't even use compression until 2.3 laid it on me. And who doesn't have to restore/move/test a Drupal development site at least every other day?

So I'd say the number is pretty small. Regardless, even one vulnerable production site is one too many, but I'm guessing the philosophy here is that individuals are expected to ensure the integrity of their own data.

Though there's a fair chance I don't know what I'm talking about.

Anyway, this post is looking more like a forum conversation than an issue thread, so i'm going to shut up now.

vacho’s picture

#24 it's done for me

ar-jan’s picture

Status: Needs work » Fixed

There's an issue for the corrupted gzip backups with version 7.x-2.3: #1564408: Gzip backups are compressed twice when downloaded, which is where that discussion should continue... The problem with database field/column case was solved with 7.x-2.3.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kerasai’s picture

Thanks for getting this fixed and a new release distributed quickly. This is a very convenient tool.

tstephen’s picture

You have done noble guys, thanks so much.
Your responses are quick and you care so much for one another.
Well Done.

mariohernandez’s picture

Following the instructions on comment #5 fixed my issue. Thank you.

nicpeck’s picture

I had a similar error, though the backup seemed to work. I eventually found that it was throwing the errors when it tried to backup the custom views in my database. After I excluded the views in the backup profile it runs without any issues.

nicpeck’s picture

Issue summary: View changes

corrected types

zawaka’s picture

Thanks a lot. #22 still rocks the house. It worked on Drupal 7.3.9 + BM 7.x-2.2