Answers.Body: <p>Updating via DB should be fine, note that it won't update existing membership records to create inherited memberships.</p>
  
  <p>Issue mentioned related to <strong>Disable</strong> might be a bug. I would suggest filing an issue in bug tracker if you are able to replicate it on the demo.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-17T21:57:20.770Z
Answers.Text: Thanks. I was able to reproduce with a non-Employee relationship (Employee relationship works as expected). Bug ticket updated/linked above.
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-17T21:52:18.190Z
Answers.LastActivityDate: 2015-04-17T21:52:18.190Z
Answers.UserDisplayName: Kurund Jalmi
Body: <p>We have a membership type that is shared by relationship. However, after the membership type was created, we needed to share it by a new relationship type. I edited the membership type directly in the database to add the new relationship type (since the interface does not allow you to edit that after a membership is created). I simply added the new <strong>relationship_type_id</strong> and <strong>relationship_direction</strong> in the <strong>civicrm_membership_type</strong> table for the appropriate row.</p>
  
  <p>It seems to have been working fine, but I am tracking down a bug now and wonder if this edit may be related. (The bug does not seem to happen on the demo site).</p>
  
  <p>Here's the issue: when a relationship is disabled from the Organization or Individual's Relationship tab (ie. using the "<strong>more > Disable</strong>" command rather than editing the relationship, disabling, and saving) the membership which is shared by relationship is not disabled. When the relationship is rather edited by clicking <strong>Edit</strong>, unchecking <strong>Enabled</strong>, and saving, the membership disappears as expected. (In fact, if I do it the first way, then <strong>Edit</strong> and <strong>Save</strong> without changing anything, the membership disappears, too.)</p>
  
  <p>UPDATE: I can actually reproduce this on the demo server with a non-Employee relationship so I think it may be a bug. I <a href="https://issues.civicrm.org/jira/browse/CRM-16306" rel="nofollow">have submitted a bug ticket on JIRA</a>.</p>
  
Tags: <civimember><relationships>
Title: Are there any dangers to editing a membership type directly in the database?
ThreadText: # Are there any dangers to editing a membership type directly in the database?
  
  (Asked by: username_0 on 2015-04-17)
  
  We have a membership type that is shared by relationship. However, after the membership type was created, we needed to share it by a new relationship type. I edited the membership type directly in the database to add the new relationship type (since the interface does not allow you to edit that after a membership is created). I simply added the new **relationship\_type\_id** and **relationship\_direction** in the **civicrm\_membership\_type** table for the appropriate row.
  
  It seems to have been working fine, but I am tracking down a bug now and wonder if this edit may be related. (The bug does not seem to happen on the demo site).
  
  Here's the issue: when a relationship is disabled from the Organization or Individual's Relationship tab (ie. using the "**more > Disable**" command rather than editing the relationship, disabling, and saving) the membership which is shared by relationship is not disabled. When the relationship is rather edited by clicking **Edit**, unchecking **Enabled**, and saving, the membership disappears as expected. (In fact, if I do it the first way, then **Edit** and **Save** without changing anything, the membership disappears, too.)
  
  UPDATE: I can actually reproduce this on the demo server with a non-Employee relationship so I think it may be a bug. I [have submitted a bug ticket on JIRA](https://issues.civicrm.org/jira/browse/CRM-16306).
  
  **Tags:** civimember, relationships
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-04-17. Score: 5 | Accepted answer
  
  Updating via DB should be fine, note that it won't update existing membership records to create inherited memberships.
  
  Issue mentioned related to **Disable** might be a bug. I would suggest filing an issue in bug tracker if you are able to replicate it on the demo.
  
  > **Comments:**
  > **username_0**: Thanks. I was able to reproduce with a non-Employee relationship (Employee relationship works as expected). Bug ticket updated/linked above.  
  
  ---
  
  