Answers.Body: <p>Interim workaround is just make an export mapping that has most of the &quot;primary&quot; fields but leaves out some of the useless ones, and then tell people to use that instead of &quot;primary&quot; (or hide the primary radio and call your mapping &quot;primary&quot;). I expect you could start with leaving out the ones here: <a href="https://lab.civicrm.org/dev/core/-/issues/2784#note_66899" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues/2784#note_66899</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-13T19:22:33.707Z
Answers.Text: Thanks! I always appreciate a good work around :).
Answers.UserDisplayName: Jamie
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-10T22:45:04.577Z
Answers.LastActivityDate: 2021-12-10T22:45:04.577Z
Answers.UserDisplayName: Demerit
Answers.Body: <p>You will need to <a href="https://palantetech.coop/blog/converting-your-civicrm-database-use-emoji-emails" rel="noreferrer">convert all the CiviCRM tables to utf8mb4</a> or as a workaround convert civicrm_contact table to utf8mb4 by running below query.</p>
  <pre><code>ALTER TABLE civicrm_contact CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-13T19:23:04.280Z
Answers.Text: Yes! Thank you. I thought I had converted all of our databases, but apparently missed this one. Converting the table exactly as you described resolved the problem.
Answers.UserDisplayName: Jamie
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-24T11:48:08.603Z
Answers.Text: Wow Thanks Pradeep, I would never have thought that utf8mb4 would solve this problem, but it has for me too. Worth note: The [Uh-oh extension](https://lab.civicrm.org/extensions/uhoh) can help highlight weird db issues for you, and `cv api3 System.utf8conversion` can convert all your tables to utf8mb4.
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-12-10T23:51:33.477Z
Answers.LastActivityDate: 2021-12-10T23:51:33.477Z
Answers.UserDisplayName: Pradeep Nayak
Body: <p>There are a lot of &quot;Row size too large&quot; type errors with various different causes (for example: <a href="https://lab.civicrm.org/dev/core/-/issues/2784" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/-/issues/2784</a> and <a href="https://civicrm.stackexchange.com/questions/13131/log-table-nativecode-1118-row-size-too-large-you-have-to-change-some-column">Log table: nativecode=1118 ** Row size too large. You have to change some columns to TEXT or BLOBs</a>).</p>
  <p>But this one I haven't seen before.</p>
  <p>It happens when exporting primary fields after a search.</p>
  <p>I'm using:</p>
  <ul>
  <li>MariaDB 10.5</li>
  <li>The default ROW_FORMAT is already set to dynamic.</li>
  </ul>
  <p>The exact error is:</p>
  <pre><code>Row size too large (&gt; 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
  </code></pre>
  <p>I tracked it down to the <a href="https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/" rel="nofollow noreferrer">problem described on this mariadb page</a> which explains:</p>
  <blockquote>
  <p>The root cause is that InnoDB has a maximum row size that is roughly equivalent to half of the value of the innodb_page_size system variable.</p>
  </blockquote>
  <p>And, the default <code>innodb_page_size</code> is 16k, so we have exceeded 8k. Unfortunately, you can't change the <code>innodb_page_size</code> <a href="https://mariadb.com/kb/en/innodb-system-variables/#innodb_page_size" rel="nofollow noreferrer">without re-initializing the database</a>. That means exporting all databases, shutting down the server, changing the configuration, starting the server and re-importing all databases.</p>
  <p>It's possible to hide under a rock by setting <code>innodb_strict_mode=Off</code>, but that seems risky. I'm not entirely sure why this is the first time I've come across this problem.</p>
  <p>I'm wondering if my analsys is correct and if anyone has less drastic fixes or work-arounds?</p>
  
Tags: <mariadb>
Title: row size too large when exporting
ThreadText: # row size too large when exporting
  
  (Asked by: username_0 on 2021-12-10)
  
  There are a lot of "Row size too large" type errors with various different causes (for example: <https://lab.civicrm.org/dev/core/-/issues/2784> and [Log table: nativecode=1118 \*\* Row size too large. You have to change some columns to TEXT or BLOBs](https://civicrm.stackexchange.com/questions/13131/log-table-nativecode-1118-row-size-too-large-you-have-to-change-some-column)).
  
  But this one I haven't seen before.
  
  It happens when exporting primary fields after a search.
  
  I'm using:
  
  * MariaDB 10.5
  * The default ROW\_FORMAT is already set to dynamic.
  
  The exact error is:
  
  ```
  Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
  
  ```
  
  I tracked it down to the [problem described on this mariadb page](https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/) which explains:
  
  > The root cause is that InnoDB has a maximum row size that is roughly equivalent to half of the value of the innodb\_page\_size system variable.
  
  And, the default `innodb_page_size` is 16k, so we have exceeded 8k. Unfortunately, you can't change the `innodb_page_size` [without re-initializing the database](https://mariadb.com/kb/en/innodb-system-variables/#innodb_page_size). That means exporting all databases, shutting down the server, changing the configuration, starting the server and re-importing all databases.
  
  It's possible to hide under a rock by setting `innodb_strict_mode=Off`, but that seems risky. I'm not entirely sure why this is the first time I've come across this problem.
  
  I'm wondering if my analsys is correct and if anyone has less drastic fixes or work-arounds?
  
  **Tags:** mariadb
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-12-10. Score: 4 | Accepted answer
  
  You will need to [convert all the CiviCRM tables to utf8mb4](https://palantetech.coop/blog/converting-your-civicrm-database-use-emoji-emails) or as a workaround convert civicrm\_contact table to utf8mb4 by running below query.
  
  ```
  ALTER TABLE civicrm_contact CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  
  ```
  
  > **Comments:**
  > **username_0**: Yes! Thank you. I thought I had converted all of our databases, but apparently missed this one. Converting the table exactly as you described resolved the problem.  
  > **username_3**: Wow Thanks username_2, I would never have thought that utf8mb4 would solve this problem, but it has for me too. Worth note: The [Uh-oh extension](https://lab.civicrm.org/extensions/uhoh) can help highlight weird db issues for you, and `cv api3 System.utf8conversion` can convert all your tables to utf8mb4.  
  
  ---
  
  ### Answer by username_1 on 2021-12-10. Score: 2
  
  Interim workaround is just make an export mapping that has most of the "primary" fields but leaves out some of the useless ones, and then tell people to use that instead of "primary" (or hide the primary radio and call your mapping "primary"). I expect you could start with leaving out the ones here: <https://lab.civicrm.org/dev/core/-/issues/2784#note_66899>
  
  > **Comments:**
  > **username_0**: Thanks! I always appreciate a good work around :).  
  
  ---
  
  