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).

4 Answers 4


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.

  • 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..
    – yurg
    Commented Jul 28, 2016 at 22:11
  • 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).
    – Alan Dixon
    Commented Jul 29, 2016 at 13:10

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.


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.

  • Would splitting your Fields across more Field Groups also avoid the issue?
    – petednz - fuzion
    Commented May 2, 2018 at 19:28
  • 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.)
    – RayWright
    Commented May 2, 2018 at 19:59
  • I don't see that having Fields in different Field Groups limits how you set up your Webform or your Activity etc
    – petednz - fuzion
    Commented May 2, 2018 at 20:23
  • 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.
    – RayWright
    Commented May 2, 2018 at 20:30
  • And you should be able to just 'move' the fields from one group to another via the UI
    – petednz - fuzion
    Commented May 3, 2018 at 19:28

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.