Schema fixing updates use D6 functions and cause fatal errors

I just updated a Drupal 6.20 site running the latest Backup_Migrate release to Drupal 7.0-rc2 / Backup and Migrate 7.x-2.0-rc1 and when I visit the /admin/structure/backup_migrate/export/advanced page, the following 3 errors are displayed:

* Notice: Undefined index: source_id in backup_migrate_item->load_row() (line 315 of .../backup_migrate/includes/crud.inc).
* Notice: Undefined index: exclude_tables in backup_migrate_item->load_row() (line 315 of .../backup_migrate/includes/crud.inc).
* Notice: Undefined index: nodata_tables in backup_migrate_item->load_row() (line 315 of .../modules/backup_migrate/includes/crud.inc).

I'll do some more digging, but, thought this additional data might provide a useful clue.

^{Note to self: at.c}

Hmm, sounds like the data returned from a db load doesn't match the schema. If you look at your backup_migrate_profiles table in the db, what columns does it contain.

As requested:

backup_migrate_profiles

Looks like I had an outdated version of the schema in the install file. Unfortunately if you've already run the update from 6 to 7 there's no way to rerun it so the only current solution if you have this issue is to uninstall (not just disable) and then reinstall Backup and Migrate. You will have to recreate any custom destinations, profiles and schedules you have made. You can also go back and run the update from your saved v6 db snapshot if you haven't done your final update to 7 yet.

I started my setup with drupal-7.0-rc4 and backup_migrate-7.x-2.0-rc1;
today i updated to drupal-7.0 and backup_migrate-7.x-2.0.
Then - after cron - I get this one error-line:

Notice: Undefined index: source_id in backup_migrate_item->load_row() (Zeile 315 von /var/www/SOMEPATH/httpdocs/7.x_modules/all/backup_migrate/includes/crud.inc).

After reading this article i did a fresh installation of backup_migrate-7.x-2.0.
But the error still remains after every cron-run.

This added a bunch of incorrect calls to db_change_field() by adding a $ret parameter, which is no longer necessary and will cause fatal errors.

And this also added calls to update_sql() which does not exist in D7. I think the D6 patch got committed to D7 code. This prevents all updates from working and leaves the module with broken schema.

Thanks Dave. I've made those fixes and hopefully this should be updating cleanly now. I tested updating from an older version of the schema, but if people who had this issue could test this with the db dumps they had problems with I would appreciate it.

Thanks
Ronan

I haven't tested it yet but as it looks in the code, there is no database update script included which would be executed as the hooks in the install field have numbers '2000' which doesn't apply to a 7.x module, does it? So in other words, the current install file has a changed schema which should be fine for new installs but for existing installs it doesn't update.

subscribing...

I had the same problem - upgraded from 7.x-2.0-rc1 to 7.x-2.0 and started getting this error everytime a scheduled backup was attempted. Uninstalled the module, then reinstalled and now it's fine.

I haven't tested it yet but as it looks in the code, there is no database update script included which would be executed as the hooks in the install field have numbers '2000' which doesn't apply to a 7.x module, does it?

As far as I'm aware there are no restrictions on update numbers in D7. The will simply run in order. Somebody should correct me if I'm wrong on this.

Well, there *are* restrictions. If you install your module in version 7.2 then this will be registered in the system table with schema version 7200 and from that point on the next update to that schema should be 7201. Otherwise the update won't be recognised.

Yes that is true. So if you have performed the update during the period when the interim updates were missing your schema will be broken and the only choice you have is to uninstall and reinstall the module. If I add the interim functions back with higher numbers at this point they will cause errors for a lot more people so I'm really not sure what else I can do at this point.

I'll have a stable release out soon with this fix so hopefully the damage will be limited.

I think you could easily have the update functions with higher numbers including some checks if they have been performed already, e.g. by checking if a field in the database is available or not. That would solve the problem for all users, including those who got left behind with a broken scheme because they updated instead of newly installed. Reading the issue queue makes me think that this is not that small number.

I'd be able to write the code, but I'm not able to test it as I don't have a db that has experienced this issue. This situation is specific to only people who updated from a specific version of the D6 module to a specific version of the D7 module so hopefully the fallout will be minimal.

I have attached a patch that reapplies update 2005 as update 7201. If I get enough people reviewing it on this thread I'll consider applying it in the next major version.

"This situation is specific to only people who updated from a specific version of the D6 module to a specific version of the D7 module"

See post #15. However, I agree the fallout should be minimal. Since I uninstalled and re-installed I've had no further errors.

Thanks, patch in #20 worked great for me, got rid of all errors and I was able to run scheduled backups again. Like in Matt B's case, I was having errors on a site which was never upgraded from D6, but started as a D7 site.

The patch from #20 worked for me, once the db updates were applied. This is on a site upgraded from D6 to D7.

I can report success with the #20 patch the same as #22. I finally got around to addressing this issue today on a dev site. Thank you!

The Undefined index notice for 'exclude_tables' and for 'nodata_tables' can be triggered on other way too.

1) If you have a saved profile,
2) then add a new DB connection to the $databases in the settings.php
3) go to profile edit form
4 ) Notice: Undefined index: exclude_tables in backup_migrate_destination_db->backup_settings_form()
Notice: Undefined index: nodata_tables in backup_migrate_destination_db->backup_settings_form()

Could be related: #1253502: Add support for PostgreSQL databases (this one's a duplicate)
based on that #1016122: Scheduled backups failing is duplicated to this.

I'm getting this error (I think it's the same at least) in D7.
I downloaded the patch, but I don't know how to apply the patch. Could someone tell me please?
I figured it out, but didn't work. I might have another problem alltoghether.

Is this still an issue with 7.x-3.2 about 7 years after it was first reported on a much earlier version of Backup and Migrate?

Closing after more than two weeks with no activity.