Upgrading CiviCRM from 4.6.26 to 4.7.16 is failing at step Upgrade DB to 4.7.beta6: SQL with the following error:

ALTER TABLE civicrm_event ADD COLUMN max_additional_participants int(10) unsigned DEFAULT 0 COMMENT 'Maximum number of additional participants that can be registered on a single booking' AFTER is_multiple_registrations [nativecode=1118 ** Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.]

Everything I can find says that this is a fairly fundamental MySQL restriction but I can't find any much trace of people hitting it with CiviCRM at all.

The MySQL server version is 5.5.54 which should be supported, and I have tried increasing the InnoDB log file size from 5Mb to 48Mb as some things say that will help but it made no difference.

  • 1
    Hi - Are you running multi-lingual? CiviCRM's multi language adds extra columns to the tables and this has caused us problems in the past. If you could confirm we can probably advise how to get round the issue. Commented Feb 12, 2017 at 19:16
  • Yes, it appears that it is in multi-lingual mode...
    – TomH
    Commented Feb 13, 2017 at 0:11

2 Answers 2


Ok so the problem is Multi Lingual with CiviCRM adds a per language column to the tables where its needed. In the case of the civi_event table this is one of the most troublesome as it has quite a lot of columns that are needed in the different languages.

What I've done to get round this in the past is clear out the relevant data from the fields i.e. create a copy of civi_event as it stands, delete the data in the multilingual description and then try the upgrade again. This was in the earlier versions of MySQL where the rowsize wasn't really controllable.

More recent versions of MySQL have some config options to allow you to setup your MySQL a little differently, I haven't tried the file format options in this thread but we do run table per file regularly.


Please do let us know how you get on, its a common problem for multi language CiviCRM installs.

  • So I went with the advice from stackoverflow.com/questions/15585602/… and switched to the Barracuda format and changed civicrm_event to ROW_FORMAT=DYNAMIC and that has solved the problem.
    – TomH
    Commented Feb 13, 2017 at 14:23
  • Thats good to know, thanks for the update. Commented Feb 13, 2017 at 15:55
  • I would add that, with my database designers hat on, I agree with some of the comments in that question that it's likely to be a sign of poor database design - certainly in this case adding columns per language is an unusual way of handling things and moving those columns to a separate table keyed per language would likely be better ;-)
    – TomH
    Commented Feb 13, 2017 at 16:01
  • Yep, agree and I first hit this issue back in 2010, problem is none of our multi lingual work has been large enough to justify a refactor of the work. Hopefully a large multi lingual implementation would take the refactor on! Commented Feb 13, 2017 at 16:04

I have this issue with an upgrade to 5.35.1 from 5.30.1. In my case, it was due to the fact that the site was originally installed with mariadb 10.1 and later upgraded to 10.2. My solution was to convert the row formats to dynamic as TomH does above.

Here's a little mysql to generate those convert statements:

SELECT GROUP_CONCAT(CONCAT('ALTER TABLE `', table_name, '` ROW_FORMAT=DYNAMIC') SEPARATOR ';') AS aquery FROM information_schema.tables where table_schema = 'yourdbname';

That will spit out a long statement that you can execute from the mysql command line to convert all your tables.

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.