CiviCRM Community Forums (archive)

Hi All,

I'm very new to CiviCRM so please be gentle!  I have recently taken over management of our organisation's website including CiviCRM and my first admin task was to upgrade CiviCRM to 4.5.2 (from 4.5.1).

I followed the instructions here and everything seemed to go through without a problem.  In particular, running the DB upgrade reported that it had completed successfully.

Our site runs on Drupal and we have separate DBs for Drupal and CiviCRM.

However, since the upgrade we are getting some weird DB errors.  The most obvious one is after logging in to our site, when we get this error message:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'aevaasna_maindrupal.civicrm_group' doesn't exist: SELECT cgr.group_id AS group_id FROM {civicrm_group_roles_rules} cgr INNER JOIN {civicrm_group} cg ON cg.id = cgr.group_id WHERE (cgr.role_id = :db_condition_placeholder_0) AND (cg.saved_search_id IS NULL ) ; Array ( [:db_condition_placeholder_0] => 3 ) in civicrm_group_roles_add_remove_groups() (line 664 of /home/aevaasna/public_html/sites/all/modules/civicrm/drupal/modules/civicrm_group_roles/civicrm_group_roles.module).
Strangely, if I go back to our site home page, I find that I'm logged in.

I've tried googling this error but haven't found anything obviously relevant.  I've also hunted through this forum.  Is there an upgrade log file I can check to ensure there wasn't some error I somehow missed during the upgrade process?  Where else should I look for to try and work out what the problem is?

TIA,

Rob Hills
Waikiki, Western Australia

Thanks for pointing out that thread, you're correct that it seems to be a very similar problem.

However, as I pointed out in my original post, I have CiviCRM in a separate DB from Drupal (unlike the poster you referred to) and the table concerned does indeed exist where it is supposed to (ie in the CiviCRM DB) but CiviCRM is trying to find it in the wrong DB at this point in the code anyway.

This doesn't seem to be a global DB problem as we've had someone complete a registration online today and their contact details etc have made their way into the CiviCRM DB OK.

Cheers,

Rob Hills
Waikiki, Western Australia

Thanks for your reply Donald,

OK, so as you've said it seems that the civicrm_group_roles module is not aware that CiviCRM is in a different DB.  I've developed in a number of languages, but never php.  I've hunted through the source code for this module but I've not been able to work out how a module "learns" about the database.  Where do I look for this?

I suspect I should move this discussion over to the civicrm-drupal forum, is that right?

Cheers,

Rob Hills
Waikiki, Western Australia

I would definitely file a bug report, and I would keep on bug hunting since you are doing a good job so far!

db_select is a drupal function for selecting from MySQL - CRM_Core_DAO::executeQuery is the CivICRM way.  Which seems to me to be consistent with what you are saying.

I had a look at the history for the module and it looks like civicrm_group_roles/civicrm_group_roles.module was changed by davejenx to better handle smart groups https://issues.civicrm.org/jira/browse/CRM-11161. 

If you look here https://github.com/civicrm/civicrm-drupal/commit/f0a43f0662f2e17da4f6b34786b7014a3eec9a29#diff-2211682bb469d77fc28523d608c4564cR660, you'll see that it is trying to join to a civicrm table which for whatever reason it can't find (before it was just querying drupal tables).  So sounds like we might have identified the problem - just not sure what the solution is yet
 
I've let Dave know so he can comment.

The problem with the approach suggested in the Views3 integration is that it doesn't take account of the situation where the drupal and civicrm databases have different user/password combinations. Or are not even stored within the same database server. Drupal these days has a very nice database connection array approach in the settings.php file which civicrm presumably already makes use of. Why can't the Views3 module (and the groups integration, which is causing us a problem right now) make use of it in the same way:


db_set_active(CIVI_DB_NAME AS DEFINED IN SETTINGS.PHP);
 CODE DOING STUFF WITH CIVI DATABASE TABLES GOES HERE
db_set_active();
 CODE DOING STUFF WITH DEFAULT DATABASE GOES AFTER A NULL CALL TO db_set_active();

Hi Dave,

Thanks for the patch and sorry for the delay, I've been away at a conference.  I'll apply your patch during today and report back on the outcome.

Later tonight (Western Australian time, UTC +8H), I plan to upgrade Drupal (7.31 -> 7.34) and CiviCRM (4.5.3->4.5.4) so I will reapply the patch after that and report back again on how it goes with the new versions.

Cheers,

I would definitely file a bug report...

OK, I've done that: https://issues.civicrm.org/jira/browse/CRM-15644

DaveJ - thank you so much!

Just upgraded from civi 4.4 to 4.5 today and started getting these errors. Applied the patch and it seems to have sorted it out.

Many many thanks for this!