Answers.Body: <p>Do you have civicrm_entity installed? See <a href="https://www.drupal.org/project/civicrm_entity/issues/3299224#comment-15013847" rel="nofollow noreferrer">https://www.drupal.org/project/civicrm_entity/issues/3299224#comment-15013847</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-05-07T14:27:12.757Z
Answers.Text: I have, and that would explain why these tables are created in the wrong database. I'm not sure if it explains why a drupal core update would try to use those tables ..
Answers.UserDisplayName: commonpike
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-05-07T12:26:21.120Z
Answers.LastActivityDate: 2023-05-07T12:26:21.120Z
Answers.UserDisplayName: Demerit
Body: <p>I've installed Drupal (9) and CiviCRM (5.59) in separate databases using <code>drush site:install</code> and <code>cv core:install</code> in that order. The drupal database connection is set in <code>settings.php</code>, and the civi database connection is set in <code>civicrm.settings.php</code>.</p>
  <p>It works, until it doesn't.</p>
  <p>Amongst others (I think), on a Drupal core update, Civi believes it lives in the Drupal database and tries to run tests there. It doesn't have the right permissions (TRIGGERS and such), and everything fails. It also creates all civi tables in the drupal db (I think already on <code>drush site:install</code>, which it never uses during operation.</p>
  <p>What is wrong ? How can I tell CiviCRM to always work in it's own database ?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-05T14:59:07.930Z
Comments.Text: Did you find a solution for this? I'm running into the same problem... Thanks, Mathias
Comments.UserDisplayName: mathiasp
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-05T18:19:44.887Z
Comments.Text: Hi Mathias - as this wasn't an "Answer" so i will convert to a Comment - perhaps you don't have enough reps to 'comment' yourself. Other option is to open your own Question, link to this, but provide extra info about your own set up (but of course if your issue is identical then a 'me too' is a valid comment)
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-06T08:08:30.633Z
Comments.Text: @mathiasp I have, and that would explain why these tables are created in the wrong database. I'm not sure if it explains why a drupal core update would try to use those tables
Comments.UserDisplayName: commonpike
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-11-06T16:15:29.430Z
Comments.Text: @mathiasp , no, I never found a real solution for this. However, iirc, it works ok if you make civicrm a dependency of (in my case) a required module and insert the civi database credentials in settings.php **before** you run `drush site:install`. Then, there is no need to run `cv core:install`, because it gets installed by site: install.
Comments.UserDisplayName: commonpike
Tags: <database><drupal-9>
Title: CiviCRM in a separate database keeps testing the Drupal database on update
ThreadText: # CiviCRM in a separate database keeps testing the Drupal database on update
  
  (Asked by: username_0 on 2023-05-07)
  
  I've installed Drupal (9) and CiviCRM (5.59) in separate databases using `drush site:install` and `cv core:install` in that order. The drupal database connection is set in `settings.php`, and the civi database connection is set in `civicrm.settings.php`.
  
  It works, until it doesn't.
  
  Amongst others (I think), on a Drupal core update, Civi believes it lives in the Drupal database and tries to run tests there. It doesn't have the right permissions (TRIGGERS and such), and everything fails. It also creates all civi tables in the drupal db (I think already on `drush site:install`, which it never uses during operation.
  
  What is wrong ? How can I tell CiviCRM to always work in it's own database ?
  
  **Tags:** database, drupal-9
  
  > **Comments:**
  > **username_1**: Did you find a solution for this? I'm running into the same problem... Thanks, Mathias  
  > **username_2**: Hi Mathias - as this wasn't an "Answer" so i will convert to a Comment - perhaps you don't have enough reps to 'comment' yourself. Other option is to open your own Question, link to this, but provide extra info about your own set up (but of course if your issue is identical then a 'me too' is a valid comment)  
  > **username_0**: @username_1 I have, and that would explain why these tables are created in the wrong database. I'm not sure if it explains why a drupal core update would try to use those tables  
  > **username_0**: @username_1 , no, I never found a real solution for this. However, iirc, it works ok if you make civicrm a dependency of (in my case) a required module and insert the civi database credentials in settings.php **before** you run `drush site:install`. Then, there is no need to run `cv core:install`, because it gets installed by site: install.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2023-05-07. Score: 2
  
  Do you have civicrm\_entity installed? See <https://www.drupal.org/project/civicrm_entity/issues/3299224#comment-15013847>
  
  > **Comments:**
  > **username_0**: I have, and that would explain why these tables are created in the wrong database. I'm not sure if it explains why a drupal core update would try to use those tables ..  
  
  ---
  
  