Body: <p>I've been bumping into a field limit when attempting to mirgrate fields in, which is a massive limitation for the way the site was originally set up.</p>
  
  <p>I've read a bunch of other threads where it's suggested changing the table to barracuda and dynamic</p>
  
  <p>I've added this to the mysql conf:</p>
  
  <pre><code>innodb_file_per_table=1
  innodb_file_format = Barracuda
  innodb_log_file_size = 512M
  innodb_strict_mode = 0
  </code></pre>
  
  <p>And I've ran <code>ALTER TABLE craftcms.craft_content ROW_FORMAT=DYNAMIC</code></p>
  
  <p>I've confirmed that this has all been updated in <code>INNODB_SYS_TABLES</code> and <code>GLOBAL_VARIABLES</code> in the information_schema, but it doesn't seem to make any difference.</p>
  
  <p>Just as a test to see when I hit the limit, I've added a load of test plain text fields - the result is 219 custom fields:</p>
  
  <ul>
  <li>125 TEXT</li>
  <li>51 VARCHAR(255)</li>
  <li>37 TINYINT(1)</li>
  <li>4 VARCHAR(2000)</li>
  <li>1 TINYINT(2)</li>
  <li>1 DECIMAL(3,1)</li>
  </ul>
  
  <p>I appreciate that refactoring some of the data structure is the way forward, but given that migrating the data won't be an easy task, I'd obviously prefer if there's some database solution to mitigate this issue quickly.</p>
  
  <p>Any suggestions?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-07-05T21:45:00.677Z
Comments.Text: I don't have an answer for you and it looks like you've got a solid grasp on the problem already. Worth mentioning that as part of this (https://github.com/craftcms/cms/issues/1524), that would involve having a content table per field set (instead of lumping them all into craft_content), which would alleviate this type of thing going forward.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-07-06T07:34:30.887Z
Comments.Text: Whilst that does sound like a great idea, it looks like that's currently scheduled for Craft 4.0? So as of Craft 2.6.X is the answer just delete a lot of fields and slowly migrate content into something like Super Table to group the content in separate fields?
Comments.UserDisplayName: Jammooka
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-07-06T18:36:18.157Z
Comments.Text: Yeah... Super Table or Matrix. Wish I knew of a better answer.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-17T14:03:57.653Z
Comments.Text: I run into the same problem on a website with a lot of custom fields. Disabling strict mode in mysql and increasing the log file size to 512MB seems to have fixed the issue so far. Hopefully the aforementioned enhancement will address this issue in a better way.
Comments.UserDisplayName: Panos Spiliotis
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-19T09:20:51.973Z
Comments.Text: If it helps, I found the easiest way to get rid of fields was to just group similar fields. So for example, all my globals are now in super tables entitled "links", "ctaFeatures" and "globals". Then we use neo so for each block type I have a content tab and a settings tab and the settings are grouper in super tables - background, text colour and border colour, for example.
Comments.UserDisplayName: Jammooka
Tags: <database><error><limit>
Title: Cannot add more fields - SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large
ThreadText: # Cannot add more fields - SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large
  
  (Asked by: username_0 on 2018-07-05)
  
  I've been bumping into a field limit when attempting to mirgrate fields in, which is a massive limitation for the way the site was originally set up.
  
  I've read a bunch of other threads where it's suggested changing the table to barracuda and dynamic
  
  I've added this to the mysql conf:
  
  ```
  innodb_file_per_table=1
  innodb_file_format = Barracuda
  innodb_log_file_size = 512M
  innodb_strict_mode = 0
  
  ```
  
  And I've ran `ALTER TABLE craftcms.craft_content ROW_FORMAT=DYNAMIC`
  
  I've confirmed that this has all been updated in `INNODB_SYS_TABLES` and `GLOBAL_VARIABLES` in the information\_schema, but it doesn't seem to make any difference.
  
  Just as a test to see when I hit the limit, I've added a load of test plain text fields - the result is 219 custom fields:
  
  * 125 TEXT
  * 51 VARCHAR(255)
  * 37 TINYINT(1)
  * 4 VARCHAR(2000)
  * 1 TINYINT(2)
  * 1 DECIMAL(3,1)
  
  I appreciate that refactoring some of the data structure is the way forward, but given that migrating the data won't be an easy task, I'd obviously prefer if there's some database solution to mitigate this issue quickly.
  
  Any suggestions?
  
  **Tags:** database, error, limit
  
  > **Comments:**
  > **username_1**: I don't have an answer for you and it looks like you've got a solid grasp on the problem already. Worth mentioning that as part of this (https://github.com/craftcms/cms/issues/1524), that would involve having a content table per field set (instead of lumping them all into craft_content), which would alleviate this type of thing going forward.  
  > **username_0**: Whilst that does sound like a great idea, it looks like that's currently scheduled for Craft 4.0? So as of Craft 2.6.X is the answer just delete a lot of fields and slowly migrate content into something like Super Table to group the content in separate fields?  
  > **username_1**: Yeah... Super Table or Matrix. Wish I knew of a better answer.  
  > **username_2**: I run into the same problem on a website with a lot of custom fields. Disabling strict mode in mysql and increasing the log file size to 512MB seems to have fixed the issue so far. Hopefully the aforementioned enhancement will address this issue in a better way.  
  > **username_0**: If it helps, I found the easiest way to get rid of fields was to just group similar fields. So for example, all my globals are now in super tables entitled "links", "ctaFeatures" and "globals". Then we use neo so for each block type I have a content tab and a settings tab and the settings are grouper in super tables - background, text colour and border colour, for example.  
  
  ---
  
  ## 0 answers
  
  