views:

74

answers:

4

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."

The table consists of about 400 varchar(max) fields. We are, however, only inserting empty strings into these fields.

The insert seems to work, however when using SqlXml to read the data or when running "DBCC DBREINDEX" on the primary key of the table, the error occurs.

It is only occurring on one particular SQL Server (2005) and not on others (2005 Express). The problem machine is running 64-bit Windows and the others are running 32-bit windows.

Has anyone got any ideas about this? Please let me know if I need to include any more information.

EDIT: Having read some of your responses, I'd like to point out that I completely agree that it is rather extreme, unusual and not at all sensible to be attempting to use this many varchar(max) columns. There are reasons for it, mainly not under my control, that I will not go into here.

A: 

Split the table into multiple.

TomTom
+1  A: 

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?

Oded
+1  A: 

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

Martin Smith
Many thanks for your response that has given me some useful information, although I have completely recreated the table, so I don't believe that can be the problem.
EasyTimer
+1  A: 

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:

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-bit pointer instead. You can read about this here:

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.

Kragen
Many thanks for your response. The whole thing is much clearer now. I agree that it is not at all advisable to use this amount of varchar(max) columns, however your third link really explained what the limits actually are and why, ignoring what is sensible. Your figure of 8000/24 makes sense, since each varchar(max) will have a 24 byte pointer to the real data. Thanks again and I'll get back to reality and shorten some of the columns and split up the table.
EasyTimer
@EasyTimer - Glad to know I helped :-)
Kragen