Answers.Body: <p>It sounds like you may have a smart group that relies on a custom field which you have since disabled or deleted. See if you can find the id of the smart group in that huge backtrace. Or else try re-enabling that field to see if the problem resolves itself.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-07T09:00:01.770Z
Answers.Text: Thanks for the hint. I found out in a different way. I did not find custom_39 in the civicrm database, but I could in the drupal database cache tables.
Answers.UserDisplayName: ñull
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-28T22:53:51.867Z
Answers.Text: @ñull How did you take care of it in the cache tables?
Answers.UserDisplayName: ermSO
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-29T11:18:04.710Z
Answers.Text: I used the cache tables to analyse the issue, not to solve the issue. How I took care of it is in the answer below.
Answers.UserDisplayName: ñull
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-06T17:39:44.660Z
Answers.LastActivityDate: 2015-10-06T17:39:44.660Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>I discovered that the issue was related to the extension <strong>Auto Group Assignments (org.amnesty.es.autogroupassignments)</strong>. I had this deinstalled, but apparently does not do so correctly. Both disabling and deinstalling gives DB already exist errors. I can now only edit/create groups with this extension activated. </p>
  
  <p>The work around is to do a manual but partial clean-up after deinstall:</p>
  
  <ul>
  <li>drop table <strong><em>civicrm_value_automatic_group_assignments</em></strong> (and <em>possibly <strong>log_civicrm_value_automatic_group_assignments</em></strong>)</li>
  <li>delete <strong><em>Affects_API_calls</em></strong> and <strong><em>Default_Group_for_New_Contacts</em></strong> from <em>civicrm_custom_field</em></li>
  <li>delete <strong><em>Automatic_Group_Assignments</em></strong> from <strong><em>civicrm_custom_group</em></strong></li>
  </ul>
  
  <p>This however still leaves you with a <em>DB exist</em> error when you reinstall the extension</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-07T09:02:06.703Z
Answers.LastActivityDate: 2015-10-07T11:10:45.740Z
Answers.LastEditDate: 2015-10-07T11:10:45.740Z
Answers.UserDisplayName: ñull
Body: <p>This error comes up when I try to edit or create a group:</p>
  
  <blockquote>
    <p>Sorry but we are not able to provide this at the moment. The field
    'custom_39' has no associated option list.</p>
  </blockquote>
  
  <p>It produces a 732K long error log that I will not paste here. Any hints how I would debug this one. </p>
  
Tags: <custom-fields><groups>
Title: The field 'custom_39' has no associated option list
ThreadText: # The field 'custom_39' has no associated option list
  
  (Asked by: username_0 on 2015-10-06)
  
  This error comes up when I try to edit or create a group:
  
  > Sorry but we are not able to provide this at the moment. The field
  > 'custom\_39' has no associated option list.
  
  It produces a 732K long error log that I will not paste here. Any hints how I would debug this one.
  
  **Tags:** custom-fields, groups
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-10-06. Score: 1
  
  It sounds like you may have a smart group that relies on a custom field which you have since disabled or deleted. See if you can find the id of the smart group in that huge backtrace. Or else try re-enabling that field to see if the problem resolves itself.
  
  > **Comments:**
  > **username_0**: Thanks for the hint. I found out in a different way. I did not find custom_39 in the civicrm database, but I could in the drupal database cache tables.  
  > **username_2**: @username_0 How did you take care of it in the cache tables?  
  > **username_0**: I used the cache tables to analyse the issue, not to solve the issue. How I took care of it is in the answer below.  
  
  ---
  
  ### Answer by username_0 on 2015-10-07. Score: 1
  
  I discovered that the issue was related to the extension **Auto Group Assignments (org.amnesty.es.autogroupassignments)**. I had this deinstalled, but apparently does not do so correctly. Both disabling and deinstalling gives DB already exist errors. I can now only edit/create groups with this extension activated.
  
  The work around is to do a manual but partial clean-up after deinstall:
  
  * drop table ***civicrm\_value\_automatic\_group\_assignments*** (and *possibly **log\_civicrm\_value\_automatic\_group\_assignments***)
  * delete ***Affects\_API\_calls*** and ***Default\_Group\_for\_New\_Contacts*** from *civicrm\_custom\_field*
  * delete ***Automatic\_Group\_Assignments*** from ***civicrm\_custom\_group***
  
  This however still leaves you with a *DB exist* error when you reinstall the extension
  
  
  ---
  
  