Change database table prefix

thanks for the patch, I'll check it out when I get a chance

Just so everyone tracks both threads - there's also a patch from greggles at on this same issue http://drupal.org/node/289263 for version 6.x.

This is a different, and much more complex issue than is addressed in #289263: Support table prefixes in table lists.

I'm moving this to version 2 as I'd like version 1 to be feature stable at this point, and this is a pretty major piece of functionality. I will need to refactor this code significantly to work with v2, but this is a great start, thanks for your hard work bsaghy.

Hi, I have the same problem here and am sorely missing this functionality in the drupal 6 version of the module!

when having multiple sites on a single database, and/or multiple instances(test, development, production) of the same, which ae differentiated by db prefix, I don't want to backup other sites in one site's admin interface, and especially not restore them.

and with more than 2 it becomes impossible to select all not-needed tables for exclusion.

Admittedly, maybe sometimes and admin might want to backup all accessible tables - but usually, when multiple people/sites share a single db (for cost reasons), they should not even see each other's databases.

Hmm, I thought I uploaded a patch here but somehow didn't?!

But I was missing another change anyway(I don't really understand why there's two methods doing exactly the same...)

One patch is this - the other attached - both against version 6.x-1.2 :

diff --git a/sites/all/modules/backup_migrate/backup_migrate.module b/sites/all/modules/backup_migrate/backup_migrate.module
index 8373be6..bea22d4 100644
--- a/sites/all/modules/backup_migrate/backup_migrate.module
+++ b/sites/all/modules/backup_migrate/backup_migrate.module
@@ -667,7 +667,12 @@ function _backup_migrate_get_tables() {
$out = "";
// get auto_increment values and names of all tables
$tables = db_query("show table status");
+ global $db_prefix;
while ($table = db_fetch_array($tables)) {
+ // only use the table if it starts with the right prefix
+ if ( strpos($table['Name'], $db_prefix) !== 0 ) {
+ continue;
+ }
$out[$table['Name']] = $table;
}
return $out;
@@ -689,8 +694,6 @@ function _backup_migrate_get_table_names() {
$out[$table['Name']] = $table['Name'];
}
return $out;
-
-
}

/**

Here the other patch - both are needed!

It would be nice, if admins could also replace/ overwrite the prefix of the tables (while those tables are being imported) with a different one, as discussed here.

To allow replacing (overwriting or deleting) the table prefix, the module would need to be able to replace the TablePrefix within following strings within the backup file:

DROP TABLE IF EXISTS `TablePrefix_
CREATE TABLE `TablePrefix_
INSERT INTO `TablePrefix_
 FROM `TablePrefix_
TablePrefix_accesslog\";
TablePrefix_cache\";
TablePrefix_cache_filter\";
TablePrefix_cache_menu\";
TablePrefix_cache_page\";
TablePrefix_cache_views\";
TablePrefix_sessions\";
TablePrefix_watchdog\";

... where 'TablePrefix' contains the old table prefix.

The DROP, CREATE and INSERT INTO sql-statements have a linefeed character prefixed to them, so they each appear on the beginning of a new line.

The 'str_replace' php-function (http://php.net/manual/en/function.str-replace.php) within some loop routine might be useful for this.

After i move my site from one hosting to another - where prefix was different, I always got some strange errors, after that found that prefix should be changed and i found this php solution that helps me a lot!

http://images.devshed.com/ds/stories/MySQL_table_changer/MySQL_php_table...

Developing process: http://www.devshed.com/c/a/MySQL/MySQL-Table-Prefix-Changer-Tool-in-PHP/

I believe this patch:
#1064694: Support of database table prefix in Drupal 7
takes care of the first feature request (Include only tables during a backup with the global db prefix set for the current installation).

As for feature requests #2 and #3 (Remove the table prefixes from the backup file; and: Add the prefix of the restoring installation during a restore), I don't think altering tables shold be part of the backup workflow.

Instead, set up an intermediary site and maintain a custom module to alter tables, as suggested here.

Please review the patch in #14 (changing status).

I believe the needs review status should be on the other issue.

This issue was created 10 years ago. Please re-open under the 8.x branch going forward if this is still a desired feature request.

Unassigning my self. This is stale.