Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

[Solved] Row size too large (> 8126)

Go to End

4 Posts   16823 Views


Community Member, 8 Posts

26 January 2014 at 3:50am

Hi there,

I created a *very large* object containing about 20 different Text-Fields.
When saving the object, I get the error:

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.

The messages tells me, that in the current configuration each of the Text-Fields stores 768 bytes inline and then the total allowed 8126 per row is exceeded.

Is there a way to tell Silverstripe to configure some table as innodb ROW_FORMAT = dynamic and keep the object structure?

What happens, if I do this on the database level (mysql) and make Silverstripe rebuild the structure (dev/build after model changes)?

Or maybe, is there any other solution for this problem?

Thanks in advance
and best regards



Community Member, 8 Posts

3 February 2014 at 11:42pm

The answer by myself:

I did it on the database level.

1. Make a database_dump and stop the SQL engine

2. The DB has to be configured Like:

in my.cnf section [mysqld|

innodb_file_format = Barracuda

3. Restart the SQL server

4. Fire the following SQL for every table which is affected:


Do not forget to alter also %%Name%%_Live , %%Name%%_versions if the affected table is Sitetree based.

The /dev/build command keeps this configuration unchanged.

The database backup is for your own insurance. Mysql changes the file structure of the databases on the fly.
Be aware, that the configuration is enabled for all databases on your machine.


Community Member, 14 Posts

11 June 2014 at 10:21pm

Hi there.

Thanks for that resolution. I also ran into this issue on a test SS v3.1.5 install. I note that the same issue does not exist on SS 2.x (same reproduction steps successfully allowed saving of data - SS version was only difference between two tests, no DB config changes or similar.)


Community Member, 25 Posts

4 February 2015 at 9:34pm


Thank you very much for the fix! could you please elaborate on what exactly are you changing config-wise? Also, I've noticed that the affected field has type mediumtext in the database (HTMLText in $db). Any way we could just change this to Text?