Answers.Body: <p>As Demerit mentioned, you have the same issues I reported. I don't think it's about the number of fields that's the issue, but the combination of data types. If you are receiving that error, be careful if your site is live because some of your cases will hit an error and you won't be able to view the case page.</p>
  
  <p>Here's what I did:</p>
  
  <p>If possible, you will want to delete all the custom fields and the custom group itself. Do it in phpmyadmin because it's faster. Once you have cleared the data, split the 65 fields into two custom groups. The error should go away. </p>
  
  <p>If you can't delete the custom group because you already have data, delete the custom fields and then create a new custom group to split off some of those fields.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-24T21:39:14.087Z
Answers.LastActivityDate: 2019-10-24T21:39:14.087Z
Answers.UserDisplayName: Kristine
Body: <p>In adding new custom fields to an existing set, things recently went wrong.  New entries were added in the civicrm_custom_field table, but the corresponding columns were not added to that field set's table.  This resulted in <code>DB Error: no such field</code> breaking the UI display of existing cases.  Deleting the rows from the custom_field table solved the errors so that existing cases can be viewed.</p>
  
  <p>Now new cases cannot be created.  When the new case form is submitted the case gets partially added to the db (but is not visible via the UI) and a blank error screen with message <code>DB Constraint Violation - case_type_id should possibly be marked as mandatory for Case,get API. If so, please raise a bug report.</code> appears.  Creating a new case (or trying to) adds 83000 new lines to the log file and near the top of that entry is <code>[nativecode=1054 ** Unknown column 'a_to_civicrm_value_special_case_fields_8._name_of_deleted_field_157' in 'field list']</code>.  That seems confusing since "a_to_" is not actually part of the table's name, and "_name_of_deleted_field_157" isn't in the civicrm_custom_field table.  Are custom fields recorded/stored anywhere aside from civicrm_custom_field and the fieldset they're contained by?</p>
  
  <p>Also, the field and case id's seem to have their incrementing messed up... the id#s appear to increment by 1 but there are several numbers skipped.  Is that a problem?  With the fields I deleted the row and column back to the last increment, 148, but when adding a new field its id was 155.  Can missing id's (149-154 in this case) be problematic?</p>
  
  <p>Is there anything you can suggest or point me towards in getting this working?</p>
  
  <hr>
  
  <p><em>edits:</em></p>
  
  <ul>
  <li>131 rows in civicrm_custom_field table</li>
  <li>CiviCRM 5.13.4</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T01:03:01.603Z
Comments.Text: How many custom fields do you have?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T04:55:03.470Z
Comments.Text: Missing IDs aren't problematic; this is normal behavior when a custom field is deleted.    I can't speak to the rest since I don't use CiviCase but maybe edit your question to include CiviCRM version?
Comments.UserDisplayName: Jon G - Megaphone Tech
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T14:45:21.733Z
Comments.Text: 131 fields - take a look at https://lab.civicrm.org/dev/core/issues/1330 which seems like a similar issue with the same error
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T16:34:16.337Z
Comments.Text: That's 131 fields total (so that table has 131 rows, but only 33 columns).  The largest field group is 65 fields (so its table has 65 columns, 28 fewer than the threshold they were finding in that issue on gitlab) ...do you still suspect this could be related to that as a MySql limitation?
Comments.UserDisplayName: alec
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-24T18:10:20.530Z
Comments.Text: Maybe, since row size can also depend on field name length, data type, etc. If you can do it in smaller groups it would be worth trying.
Comments.UserDisplayName: Demerit
Tags: <error><db-logging>
Title: New fields failed to get created properly, resulting in DB errors
ThreadText: # New fields failed to get created properly, resulting in DB errors
  
  (Asked by: username_0 on 2019-10-23)
  
  In adding new custom fields to an existing set, things recently went wrong. New entries were added in the civicrm\_custom\_field table, but the corresponding columns were not added to that field set's table. This resulted in `DB Error: no such field` breaking the UI display of existing cases. Deleting the rows from the custom\_field table solved the errors so that existing cases can be viewed.
  
  Now new cases cannot be created. When the new case form is submitted the case gets partially added to the db (but is not visible via the UI) and a blank error screen with message `DB Constraint Violation - case_type_id should possibly be marked as mandatory for Case,get API. If so, please raise a bug report.` appears. Creating a new case (or trying to) adds 83000 new lines to the log file and near the top of that entry is `[nativecode=1054 ** Unknown column 'a_to_civicrm_value_special_case_fields_8._name_of_deleted_field_157' in 'field list']`. That seems confusing since "a\_to\_" is not actually part of the table's name, and "\_name\_of\_deleted\_field\_157" isn't in the civicrm\_custom\_field table. Are custom fields recorded/stored anywhere aside from civicrm\_custom\_field and the fieldset they're contained by?
  
  Also, the field and case id's seem to have their incrementing messed up... the id#s appear to increment by 1 but there are several numbers skipped. Is that a problem? With the fields I deleted the row and column back to the last increment, 148, but when adding a new field its id was 155. Can missing id's (149-154 in this case) be problematic?
  
  Is there anything you can suggest or point me towards in getting this working?
  
  ---
  
  *edits:*
  
  * 131 rows in civicrm\_custom\_field table
  * CiviCRM 5.13.4
  
  **Tags:** error, db-logging
  
  > **Comments:**
  > **username_1**: How many custom fields do you have?  
  > **username_2**: Missing IDs aren't problematic; this is normal behavior when a custom field is deleted.    I can't speak to the rest since I don't use CiviCase but maybe edit your question to include CiviCRM version?  
  > **username_1**: 131 fields - take a look at https://lab.civicrm.org/dev/core/issues/1330 which seems like a similar issue with the same error  
  > **username_0**: That's 131 fields total (so that table has 131 rows, but only 33 columns).  The largest field group is 65 fields (so its table has 65 columns, 28 fewer than the threshold they were finding in that issue on gitlab) ...do you still suspect this could be related to that as a MySql limitation?  
  > **username_1**: Maybe, since row size can also depend on field name length, data type, etc. If you can do it in smaller groups it would be worth trying.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2019-10-24. Score: 1
  
  As username_1 mentioned, you have the same issues I reported. I don't think it's about the number of fields that's the issue, but the combination of data types. If you are receiving that error, be careful if your site is live because some of your cases will hit an error and you won't be able to view the case page.
  
  Here's what I did:
  
  If possible, you will want to delete all the custom fields and the custom group itself. Do it in phpmyadmin because it's faster. Once you have cleared the data, split the 65 fields into two custom groups. The error should go away.
  
  If you can't delete the custom group because you already have data, delete the custom fields and then create a new custom group to split off some of those fields.
  
  
  ---
  
  