Answers.Body: <p>It turned it is an issue related to custom fields length settings and  how CiviCRM works with MySQL at log tables creation. Simple put, CiviCRM takes custom field length and passes it to MySQL. </p>
  
  <p>CiviCRM throws an exception in case if existing data length exceeds custom field length than. Field length change in MySQL won't work since CiviCRM overrides this at each update. </p>
  
  <p>We've fixed this by increase custom field length via Civicrm UI. Debug message  (or kind of an extended explanation of what happens) would be nicer instead of MySQL <em>Row size too large</em> message though, since it is not exactly a MySQL issue, but is something caused by CiviCRM settings. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-11T11:52:15.687Z
Answers.LastActivityDate: 2016-08-11T11:52:15.687Z
Answers.UserDisplayName: yurg
Answers.Body: <p>Also worth noting that this problem can affect sites that use multilanguage since iirc the translated versions of some entities are recorded in the row and hence adds to total row size</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T19:28:02.363Z
Answers.LastActivityDate: 2018-05-02T19:28:02.363Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>I've run into the same error and to Alan's point above, yes we were creating a lot of custom fields (in our case we feel warranted.) Our solution was to lessen the database length from the standard 255 in alphanumeric fields where we knew the maximum number of characters that would be stored. In that manner we had enough room in the row to add a few more alphanumeric (varchar) fields.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T19:28:40.353Z
Answers.Text: Would splitting your Fields across more Field Groups also avoid the issue?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T19:59:29.830Z
Answers.Text: Sure would! I happen to be using the fields as part of a webform questionnaire and would prefer to report to just one activity. (That's not to say that now that I know I might hit this limit I wouldn't plan differently.)
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T20:23:22.563Z
Answers.Text: I don't see that having Fields in different Field Groups limits how you set up your Webform or your Activity etc
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T20:30:26.937Z
Answers.Text: You're saying that I could have two different custom field groups, each reporting to the same activity type. And then both sets of custom fields would be accessible on the webform. That sounds like a good solution. We were pretty far down the set up of the questionnaire when the error popped up. So adjusting a few database lengths to be able to add one or two more fields felt like the simplest work around. Again, now that I know there is a limit and in what situations I might hit it, I will probably plan differently.
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-03T19:28:55.687Z
Answers.Text: And you should be able to just 'move' the fields from one group to another via the UI
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-03T19:33:18.973Z
Answers.Text: How did I not know that 'move' was now an option!! #gamechanger
Answers.UserDisplayName: RayWright
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-03T19:41:32.883Z
Answers.Text: Great. not sure if it helps yurg though
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-05-02T18:11:17.253Z
Answers.LastActivityDate: 2018-05-02T18:11:17.253Z
Answers.UserDisplayName: RayWright
Answers.Body: <p>The column mentioned is of type varchar, which is different from text.</p>
  
  <p>Varchar data is stored differently than text (which gets a level of indirection so it's not filling up the individual row data).</p>
  
  <p>Sounds like you're creating a lot of custom field data.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-28T22:11:11.280Z
Answers.Text: Thank you Alan; afraid the column is of type text (have double-checked); have tried to change it to blob (no difference). And yes, we create a lot of custom data, shouldn't be a problem for MySQL though..
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-29T13:10:25.923Z
Answers.Text: The mysql error says that project_outline_673 is varchar. If that field is not varchar, then it would seem like your mysql is mightily confused. In general, creating that many custom fields is a flag for me that you might not be using custom fields properly. There are lots of other tools at your disposal that might be more appropriate for what you're using them for (or perhaps even CiviCRM is not the right tool).
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-28T22:00:29.390Z
Answers.LastActivityDate: 2016-07-28T22:00:29.390Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Pretty strange, since column mentioned is already of type TEXT. Full error message: </p>
  
  <pre><code> [debug_info] =&gt; ALTER TABLE `civicrm_logs`.log_civicrm_value_grants_external_application_45 
  MODIFY  `project_outline_673` varchar(4000) COLLATE utf8_unicode_ci DEFAULT NULL 
  [nativecode=1118 ** Row size too large. The maximum row size for the used 
  table type, not counting BLOBs, is 65535. 
  You have to change some columns to TEXT or BLOBs]
  </code></pre>
  
  <p>Appears after each security update right at <strong>drush cc</strong> step. No visible harm (excluding, may be, Change Log records at Contact Tab, which are in a very base format now,mean only name and date, no further details, but not sure if it's relevant).</p>
  
Tags: <mysql><logs><logging>
Title: Log table: nativecode=1118 ** Row size too large. You have to change some columns to TEXT or BLOBs
ThreadText: # Log table: nativecode=1118 ** Row size too large. You have to change some columns to TEXT or BLOBs
  
  (Asked by: username_0 on 2016-07-28)
  
  Pretty strange, since column mentioned is already of type TEXT. Full error message: 
   [debug_info] => ALTER TABLE `civicrm_logs`.log_civicrm_value_grants_external_application_45 
  MODIFY  `project_outline_673` varchar(4000) COLLATE utf8_unicode_ci DEFAULT NULL 
  [nativecode=1118 ** Row size too large. The maximum row size for the used 
  table type, not counting BLOBs, is 65535. 
  You have to change some columns to TEXT or BLOBs]
  
  Appears after each security update right at drush cc step. No visible harm (excluding, may be, Change Log records at Contact Tab, which are in a very base format now,mean only name and date, no further details, but not sure if it's relevant).
  
  **Tags:** mysql, logs, logging
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_0 on 2016-08-11. Score: 0 | Accepted answer
  
  It turned it is an issue related to custom fields length settings and how CiviCRM works with MySQL at log tables creation. Simple put, CiviCRM takes custom field length and passes it to MySQL.
  
  CiviCRM throws an exception in case if existing data length exceeds custom field length than. Field length change in MySQL won't work since CiviCRM overrides this at each update.
  
  We've fixed this by increase custom field length via Civicrm UI. Debug message (or kind of an extended explanation of what happens) would be nicer instead of MySQL *Row size too large* message though, since it is not exactly a MySQL issue, but is something caused by CiviCRM settings.
  
  
  ---
  
  ### Answer by username_1 on 2018-05-02. Score: 0
  
  Also worth noting that this problem can affect sites that use multilanguage since iirc the translated versions of some entities are recorded in the row and hence adds to total row size
  
  
  ---
  
  ### Answer by username_2 on 2018-05-02. Score: 0
  
  I've run into the same error and to Alan's point above, yes we were creating a lot of custom fields (in our case we feel warranted.) Our solution was to lessen the database length from the standard 255 in alphanumeric fields where we knew the maximum number of characters that would be stored. In that manner we had enough room in the row to add a few more alphanumeric (varchar) fields.
  
  > **Comments:**
  > **username_1**: Would splitting your Fields across more Field Groups also avoid the issue?  
  > **username_2**: Sure would! I happen to be using the fields as part of a webform questionnaire and would prefer to report to just one activity. (That's not to say that now that I know I might hit this limit I wouldn't plan differently.)  
  > **username_1**: I don't see that having Fields in different Field Groups limits how you set up your Webform or your Activity etc  
  > **username_2**: You're saying that I could have two different custom field groups, each reporting to the same activity type. And then both sets of custom fields would be accessible on the webform. That sounds like a good solution. We were pretty far down the set up of the questionnaire when the error popped up. So adjusting a few database lengths to be able to add one or two more fields felt like the simplest work around. Again, now that I know there is a limit and in what situations I might hit it, I will probably plan differently.  
  > **username_1**: And you should be able to just 'move' the fields from one group to another via the UI  
  > **username_2**: How did I not know that 'move' was now an option!! #gamechanger  
  > **username_1**: Great. not sure if it helps username_0 though  
  
  ---
  
  ### Answer by username_3 on 2016-07-28. Score: 0
  
  The column mentioned is of type varchar, which is different from text.
  
  Varchar data is stored differently than text (which gets a level of indirection so it's not filling up the individual row data).
  
  Sounds like you're creating a lot of custom field data.
  
  > **Comments:**
  > **username_0**: Thank you Alan; afraid the column is of type text (have double-checked); have tried to change it to blob (no difference). And yes, we create a lot of custom data, shouldn't be a problem for MySQL though..  
  > **username_3**: The mysql error says that project_outline_673 is varchar. If that field is not varchar, then it would seem like your mysql is mightily confused. In general, creating that many custom fields is a flag for me that you might not be using custom fields properly. There are lots of other tools at your disposal that might be more appropriate for what you're using them for (or perhaps even CiviCRM is not the right tool).  
  
  ---
  
  