Answers.Body: <p>You will need to <a href="https://palantetech.coop/blog/converting-your-civicrm-database-use-emoji-emails" rel="nofollow 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>
  <p>Alternatively, you could build the search using searchkit with all the columns you need and export the results in CSV</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T16:22:57.457Z
Answers.Text: civicrm_contact (and all the other tables I've checked) are already in utf8mb4_unicode_ci and the database default characterset is utf8mb4, so I'm not sure that's an answer for me.
  
  Building the search in SearchKit is a good suggestion though, I'll give that a try. It is literally almost 100 fields though so it'll take a bit :)
Answers.UserDisplayName: zip
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T17:07:04.023Z
Answers.Text: Actually, with SearchKit the export still takes me to the same Field Mapping, so it has the same problem.
Answers.UserDisplayName: zip
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T18:26:14.123Z
Answers.Text: See also https://lab.civicrm.org/dev/core/-/issues/2784
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-01-12T14:51:26.903Z
Answers.LastActivityDate: 2024-01-12T14:51:26.903Z
Answers.UserDisplayName: Pradeep Nayak
Body: <p>I've reviewed the other related tickets here, but the solutions either don't seem applicable or are things we've already got in place - file format and character encoding are what they need to be I think.</p>
  <p>This problem <code>Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535 </code> only appears when we are doing an export to csv. Our database is MySQL8.0 in AWS Aurora RDS. I <em>think</em> I understand the problem, but I'm hoping to get confirmation of that.</p>
  <p>We have - frankly - an absurd amount of custom fields, and this particular export has most of them in it. We first saw the problem when we increased the size of one of the select fields because the export was being truncated. The field was varchar(255), but some of the select options were long sentences, so as I understand it, the temporary table prepared for the export used that varchar(255) for it's length causing the exports to get cut off for that field. We increased that varchar to 400, and they were no longer cut off. When we do the full export though, we now get the above database error.</p>
  <p>The confirmation question: Is that description of how the exports work accurate? Temporary table with the column size set by the size of the select element (rather than anything to do with the size of the options)?</p>
  <p>This problem is only showing up in exports, which isn't <em>really</em> all that important. The solution that I have in mind is just have users split this export into two parts... I think that will work. But, is this a growing problem that we'll eventually see in normal use?</p>
  
Tags: <database><export>
Title: Database error when exporting Activities: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535
ThreadText: # Database error when exporting Activities: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535
  
  (Asked by: username_0 on 2024-01-12)
  
  I've reviewed the other related tickets here, but the solutions either don't seem applicable or are things we've already got in place - file format and character encoding are what they need to be I think.
  
  This problem `Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535`  only appears when we are doing an export to csv. Our database is MySQL8.0 in AWS Aurora RDS. I *think* I understand the problem, but I'm hoping to get confirmation of that.
  
  We have - frankly - an absurd amount of custom fields, and this particular export has most of them in it. We first saw the problem when we increased the size of one of the select fields because the export was being truncated. The field was varchar(255), but some of the select options were long sentences, so as I understand it, the temporary table prepared for the export used that varchar(255) for it's length causing the exports to get cut off for that field. We increased that varchar to 400, and they were no longer cut off. When we do the full export though, we now get the above database error.
  
  The confirmation question: Is that description of how the exports work accurate? Temporary table with the column size set by the size of the select element (rather than anything to do with the size of the options)?
  
  This problem is only showing up in exports, which isn't *really* all that important. The solution that I have in mind is just have users split this export into two parts... I think that will work. But, is this a growing problem that we'll eventually see in normal use?
  
  **Tags:** database, export
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-01-12. Score: 1
  
  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;
  
  ```
  
  Alternatively, you could build the search using searchkit with all the columns you need and export the results in CSV
  
  > **Comments:**
  > **username_0**: civicrm_contact (and all the other tables I've checked) are already in utf8mb4_unicode_ci and the database default characterset is utf8mb4, so I'm not sure that's an answer for me.  Building the search in SearchKit is a good suggestion though, I'll give that a try. It is literally almost 100 fields though so it'll take a bit :)  
  > **username_0**: Actually, with SearchKit the export still takes me to the same Field Mapping, so it has the same problem.  
  > **username_2**: See also https://lab.civicrm.org/dev/core/-/issues/2784  
  
  ---
  
  