Cannot create a row of size 8937 which is greater than the allowable maximum of 8060

Question

We are getting this error on a table in our database:

Cannot create a row of size 8937 which is greater than the allowable maximum of 8060.

Answer 1

You might have a deleted column in the table that still takes up space. Also check the "text in row" settings are the same.

Answer 2

The row size is determined by the types of the columns, not how much data you store in them.

Have 400 varchar fields in a single table tells me you are doing something wrong. Perhaps you need to normalize the schema?

Answer 3

The error is caused because you cannot have a row in SQL server which is larger than 8KB (the size of 1 page) because rows are not allowed to span pages - its a basic limit of SQL Server, you can read more about it here:

• Database Basics Quick Note - The difference in Varchar and Nvarchar data types

Note that SQL server will allow you to create the table, however if you try to actually insert any data which spans multiple pages then it will give the above error.

Of course this doesn't quite add up, because if the above was the whole truth then single VARCHAR(8000) column would fill a row in a table! (This used to be the case). SQL Server 2005 got around this limitation by allowing certain data from a row to be stored in another page, and instead leaving a 24-byte pointer instead. You can read about this here:

• How Sql Server 2005 bypasses the 8KB row size limitation
• Maximum Row Size in SQL Server 2005 to the Limit

As you can see this now means that rows can now span multiple pages, however single column rows still need to fit into a single page (hence the maximum size of a column being VARCHAR(8000)) and there is still a limit on the total number of such columns you can have (around 8000 / 24 = ~300 by my estimate)

Of course this is all missing the main point, which is that 400 wide columns on a single table is absurd!!!

You should take a long hard look at your database schema and come up with something more reasonable - you could start with choosing some more conservative estimates on column sizes (like VARCHAR(255) or VARCHAR(50)), but you really need to split some of those fields out into separate tables.

Answer 4

I have this problem today. but this table's column is small and only hundreds rows. and this table work good before. I cost many time to research.

finally, I backup this table data. I delete the table. and create same new table; then restore data. everything is ok.

It shows the old table maybe crashed inside. maybe SQL server bug. anyway, issue is gone. hope save others time.

backgroud: MS SQL 2012