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.