Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p><a href="https://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large">https://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large</a></p>
  
  <p>Please do let us know how you get on, its a common problem for multi language CiviCRM installs.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T14:23:48.830Z
Answers.Text: So I went with the advice from http://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large and switched to the Barracuda format and changed `civicrm_event` to `ROW_FORMAT=DYNAMIC` and that has solved the problem.
Answers.UserDisplayName: TomH
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T15:55:59.727Z
Answers.Text: Thats good to know, thanks for the update.
Answers.UserDisplayName: Parvez Saleh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T16:01:45.883Z
Answers.Text: 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 ;-)
Answers.UserDisplayName: TomH
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T16:04:59.220Z
Answers.Text: 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!
Answers.UserDisplayName: Parvez Saleh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-13T11:28:51.473Z
Answers.LastActivityDate: 2017-02-13T11:50:09.373Z
Answers.LastEditDate: 2017-05-23T12:38:59.763Z
Answers.UserDisplayName: Parvez Saleh
Answers.Body: <p>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.</p>
  <p>Here's a little mysql to generate those convert statements:</p>
  <pre><code>SELECT GROUP_CONCAT(CONCAT('ALTER TABLE `', table_name, '` ROW_FORMAT=DYNAMIC') SEPARATOR ';') AS aquery FROM information_schema.tables where table_schema = 'yourdbname';
  </code></pre>
  <p>That will spit out a long statement that you can execute from the mysql command line to convert all your tables.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-03-18T20:44:03.827Z
Answers.LastActivityDate: 2021-03-19T15:13:39.870Z
Answers.LastEditDate: 2021-03-19T15:13:39.870Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Upgrading CiviCRM from 4.6.26 to 4.7.16 is failing at step <code>Upgrade DB to 4.7.beta6: SQL</code> with the following error:</p>
  
  <blockquote>
    <p>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.]</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-12T19:16:05.920Z
Comments.Text: 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.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-13T00:11:57.100Z
Comments.Text: Yes, it appears that it is in multi-lingual mode...
Comments.UserDisplayName: TomH
Tags: <upgrade>
Title: Upgrade fails with Row size too large error
ThreadText: # Upgrade fails with Row size too large error
  
  (Asked by: username_0 on 2017-02-12)
  
  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.
  
  **Tags:** upgrade
  
  > **Comments:**
  > **username_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.  
  > **username_0**: Yes, it appears that it is in multi-lingual mode...  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-02-13. Score: 1 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_0**: So I went with the advice from http://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large and switched to the Barracuda format and changed `civicrm_event` to `ROW_FORMAT=DYNAMIC` and that has solved the problem.  
  > **username_1**: Thats good to know, thanks for the update.  
  > **username_0**: 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 ;-)  
  > **username_1**: 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!  
  
  ---
  
  ### Answer by username_2 on 2021-03-18. Score: 1
  
  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 username_0 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.
  
  
  ---
  
  