Question

I am in the process of doing a data migration from OpenCart into Drupal 7. I have my primary database which is setup specifically for Drupal 7. Drupal is installed. I have created a secondary database on the same server which is a copy of the OpenCart database that I will be migrating from.

I did this because there are a lot of overlapping tables and honestly I didn’t really want to merge the two databases together since I will be dumping the OpenCart one just as soon as the products and related info is migrated over.

Anyway, I am finding that even though Drupal 7 easily supports this it seems to crap out the second you try to execute any queries on the secondary DB. By crap out I mean “white screen of death” crap out. If I enable the db query logging of the devel module then it outputs a few unformatted lines of that info on the WSOD.

Below is a sample of the code that I am using to do this. As you can see, even a simple select statement bombs entirely. Does anyone have any idea why this might be happening?

I would really like to make this work and do it with the migrate module. But I am about to throw my hands up and just write a custom script to connect to the database and output all of the data as a giant XML file and then hope that the migrate module can handle that (or import the aggregated data into a temp table at some point).

$query = Database::getConnection('opencart', 'opencart')->query("SELECT * FROM product");

if ($query != NULL) {
  $row = $query->execute()->fetchObject();
  echo "<pre>" . print_r($row, true) . "</pre>";
  echo "<pre>" . print_r($query, true) . "</pre>";
}
else {
  echo "Query is NULL.";
}

Answer 1

The way I’ve done this before is:

1- Edit your active settings.php file to include the secondary db in your $databases array. So you’d have something like

$databases = array(
  'default'=> array(...),
  'secondary' => array(...),
);

2- In your code, use db_set_active('secondary'); You can then execute db_query()s and possibly the likes of db_select(), etc.

3- Make sure to switch your active database back to the default as soon as possible. Watch out for function calls you make before you switch back to the default database. Many calls, like t(), require the default database, and will crap out it’s not active.