Answers.Body: <p>this might be a mariadb config issue. </p>
  
  <pre><code># enable large indexes and Barracuda
  # for utf8mb4
  innodb_file_per_table=1
  innodb_file_format=Barracuda
  innodb_large_prefix=1
  </code></pre>
  
  <p>might also change the tables to
  ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
  see this post for much more info on this front <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>but <strong>do not</strong> follow the suggestion there to alter the tables to use MyISAM instead of INNODB, that's a really bad idea. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-08T16:53:00.430Z
Answers.Text: Looks like I already made the overall config change to deal with a CiviCRM upgrade a while back (glad I left a note to myself in a config comment).
  
  So, at this point I should be able to alter the ROW_FORMAT to DYNAMIC or COMPRESSED and that will be a safe change and persist through CiviCRM upgrades?
Answers.UserDisplayName: kapn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-16T16:53:58.883Z
Answers.Text: yes, that change is safe and will persist
Answers.UserDisplayName: ericG
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-08T15:57:43.367Z
Answers.LastActivityDate: 2019-10-08T15:57:43.367Z
Answers.UserDisplayName: ericG
Answers.Body: <p>Adding this for ease of reference... In addition to the above innodb config, you will need to check the tables as @Keith Nunn alluded to. There are two tables that may need tweaking, SQL code below (row format is the key, but no harm to make sure block size and engine are set):-</p>
  
  <pre><code>ALTER TABLE civicrm_contribution_page
  ENGINE=InnoDB
  ROW_FORMAT=COMPRESSED 
  KEY_BLOCK_SIZE=8;
  
  ALTER TABLE civicrm_event
  ENGINE=InnoDB
  ROW_FORMAT=COMPRESSED 
  KEY_BLOCK_SIZE=8;
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-17T05:14:18.303Z
Answers.Text: I would advise against using 
  ROW_FORMAT=COMPRESSED 
  there's a good amount of overhead spent in compressing/decompressing data.
  unless there's a specific need for that,
  ROW_FORMAT=DYNAMIC ,
  has been a better option for the sites I deal with
Answers.UserDisplayName: ericG
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-20T12:17:11.873Z
Answers.Text: @ericG thanks for the heads up. We'll keep an eye on the performance and tweak if needed. The customer doesn't have that many events or contribution pages so hopefully won't be an issue.
Answers.UserDisplayName: Darren
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-01-16T12:46:18.720Z
Answers.LastActivityDate: 2020-01-16T12:46:18.720Z
Answers.UserDisplayName: Darren
Body: <p>I'm using CiviCRM in multilingual mode. I can generally create events (and other objects) fine. However, I often run into update problems at some point. The interface will "spin" and never save. </p>
  
  <p>Looking at the CiviCRM error log reveals a database error: </p>
  
  <pre><code>nativecode=1118 ** Row size too large (&gt; 8126)
  </code></pre>
  
  <p>I have looked at this clearly related case: <a href="https://civicrm.stackexchange.com/questions/31632/database-error-when-using-civicrm-admin-ui-row-size-too-large">Database error when using CiviCRM admin UI: &quot;Row size too large&quot;</a></p>
  
  <p>I have tried (with some trepidation because I haven't worked on the Civi backend yet and don't know where the pitfalls are) to change the ROW_FORMAT of Civicrm_event_en_CA to Dynamic, but am told that it is not a base table.</p>
  
  <p>I'm not really clear as I am more of a db user than a programmer, but assume that this table is somehow subsidiary to civicrm_event.</p>
  
  <p>That table is set to ROW_TYPE=COMPACT. I'm game to change it, but it seems drastic enough that I am wondering:</p>
  
  <ol>
  <li>Is it safe to do so WRT to CiviCRM operation?</li>
  <li>Will it persist through a CiviCRM upgrade or will it revert (and potentially throw away data)?</li>
  </ol>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-02T10:18:26.083Z
Comments.Text: Hi Keith, this maybe not cure your issue totally as it really depends on how many languages you have enabled. CiviCRM adds columns for every language you enable and sooner or later you'll start to hit limits. To get a better understanding of things it would be good to know the version of MySQL/MariaDB you're using.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-10-02T14:08:04.693Z
Comments.Text: Thanks Parvez. I just have two languages in this installation, though I have another client with 3. The MariaDB version is  10.1.41-MariaDB-0+deb9u1 Debian 9.9.
  My CiviCRM version here is 5.16.2
Comments.UserDisplayName: kapn
Tags: <database>
Title: Database error when saving CiviCRM event: “Row size too large”
ThreadText: # Database error when saving CiviCRM event: “Row size too large”
  
  (Asked by: username_0 on 2019-10-01)
  
  I'm using CiviCRM in multilingual mode. I can generally create events (and other objects) fine. However, I often run into update problems at some point. The interface will "spin" and never save. 
  Looking at the CiviCRM error log reveals a database error: 
  nativecode=1118 ** Row size too large (> 8126)
  
  I have looked at this clearly related case: Database error when using CiviCRM admin UI: "Row size too large"
  I have tried (with some trepidation because I haven't worked on the Civi backend yet and don't know where the pitfalls are) to change the ROW_FORMAT of Civicrm_event_en_CA to Dynamic, but am told that it is not a base table.
  I'm not really clear as I am more of a db user than a programmer, but assume that this table is somehow subsidiary to civicrm_event.
  That table is set to ROW_TYPE=COMPACT. I'm game to change it, but it seems drastic enough that I am wondering:
  
  Is it safe to do so WRT to CiviCRM operation?
  Will it persist through a CiviCRM upgrade or will it revert (and potentially throw away data)?
  
  **Tags:** database
  
  > **Comments:**
  > **username_1**: Hi Keith, this maybe not cure your issue totally as it really depends on how many languages you have enabled. CiviCRM adds columns for every language you enable and sooner or later you'll start to hit limits. To get a better understanding of things it would be good to know the version of MySQL/MariaDB you're using.  
  > **username_0**: Thanks Parvez. I just have two languages in this installation, though I have another client with 3. The MariaDB version is  10.1.41-MariaDB-0+deb9u1 Debian 9.9. My CiviCRM version here is 5.16.2  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2019-10-08. Score: 2 | Accepted answer
  
  this might be a mariadb config issue. 
  # enable large indexes and Barracuda
  # for utf8mb4
  innodb_file_per_table=1
  innodb_file_format=Barracuda
  innodb_large_prefix=1
  
  might also change the tables to
  ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
  see this post for much more info on this front https://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large
  but do not follow the suggestion there to alter the tables to use MyISAM instead of INNODB, that's a really bad idea.
  
  > **Comments:**
  > **username_0**: Looks like I already made the overall config change to deal with a CiviCRM upgrade a while back (glad I left a note to myself in a config comment).  So, at this point I should be able to alter the ROW_FORMAT to DYNAMIC or COMPRESSED and that will be a safe change and persist through CiviCRM upgrades?  
  > **username_2**: yes, that change is safe and will persist  
  
  ---
  
  ### Answer by username_3 on 2020-01-16. Score: -1
  
  Adding this for ease of reference... In addition to the above innodb config, you will need to check the tables as @Keith Nunn alluded to. There are two tables that may need tweaking, SQL code below (row format is the key, but no harm to make sure block size and engine are set):-
  ALTER TABLE civicrm_contribution_page
  ENGINE=InnoDB
  ROW_FORMAT=COMPRESSED 
  KEY_BLOCK_SIZE=8;
  
  ALTER TABLE civicrm_event
  ENGINE=InnoDB
  ROW_FORMAT=COMPRESSED 
  KEY_BLOCK_SIZE=8;
  
  > **Comments:**
  > **username_2**: I would advise against using  ROW_FORMAT=COMPRESSED  there's a good amount of overhead spent in compressing/decompressing data. unless there's a specific need for that, ROW_FORMAT=DYNAMIC , has been a better option for the sites I deal with  
  > **username_3**: @username_2 thanks for the heads up. We'll keep an eye on the performance and tweak if needed. The customer doesn't have that many events or contribution pages so hopefully won't be an issue.  
  
  ---
  
  