sql - Why does my row size exceed the allowed maximum of 8060 bytes -


i have following table in sql server 2012, web edition:

create table [dbo].[mytable]  (      [id]               int            identity (1, 1) not null,      [created]          datetime       default (getdate()) not null,      [refid]            int            null,      [name]             nvarchar (128) null,      [email]            nvarchar (128) null,      [imageurl]         nvarchar (256) null,      [url]              varchar (256)  null,      [age]              tinyint        null,      [country]          varchar (6)    null,      [location]         nvarchar (192) null,      [people]           int            null,      [categories]       nvarchar (128) null,      [block]            bit            default ((0)) not null,      [generatedrevenue] int            null,      [isfemale]         bit            default ((1)) null,      [hasinstalled]     bit            null,      [keywords]         varchar (128)  null,      [brands]           nvarchar (512) null,      [source]           tinyint        null,      [alias]            varchar (65)   null,       primary key clustered ([id] asc) ); 

as far gather, total size should 3175 bytes; regularly following error, when updating table:

cannot create row of size 8068 greater allowable maximum row size of 8060.

how above result in row size of 8068?

edit: should mention table has been altered, uses change tracking , has 4 indexes.

also, if copy contents new table same definition, no errors occur while, come back.

you use change tracking. - chance - ignoring versioning part of change tracking, , resetting entries doing following?

alter table dbo.mytable disable change_tracking alter table dbo.mytable enable change_tracking 

if so, may have suspect. change tracking adds 8 bit column behind scenes every time reenable change tracking, dropped if exists. since dropping column meta operation, may have large number of dropped 8 bit columns lurking behind scenes, depending on frequency reenable change tracking.

to check this, @ system_internals_partition_columns view , see if have large number of is_dropped colums. there more reasons having many of those, way of using change tracking 1 of them.

i see remus rusanu linking article in comment (rusanu.com/2011/10/20/sql-server-table-columns-under-the-hoo‌​d): queries lists should need see if above case.

edit: in case need delete dropped columns, can rebuild clustered index table(s) have many dropped columns. means rebuilding clustered index mytable relieve of symptom.


Comments

Popular posts from this blog

PHP and MySQL WP -

android - InAppBilling registering BroadcastReceiver in AndroidManifest -

go - golang pprof for c library code -