0

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. – Parvez Saleh Feb 12 '17 at 19:16
  • Yes, it appears that it is in multi-lingual mode... – TomH Feb 13 '17 at 0:11
1

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.

https://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large

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 Feb 13 '17 at 14:23
  • Thats good to know, thanks for the update. – Parvez Saleh Feb 13 '17 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 Feb 13 '17 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! – Parvez Saleh Feb 13 '17 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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