You can see this in the Message window in Management Studio when doing updates. There will be 2 messages for every update. I was curious about this sometime ago and asked the DBA. 1 Message for creating the new record to Insert. And another message for deleting the existing row that was Deleted.

>Hi Gary,
> I need a lot of latitude I guess :)
>
> From our experience with SQL server there is no real perfomance degradation when you update all columns. We might also benefit from the fact that the database systems we work on don't really have that many updates. AS a matter of fact I would posit that most database applications are read and insert heavy with relatively small amounts of updates. We do have batch operations that operate on our databases but these are generaly stored procedure heavy outside of our CRUD style of applications.
>
>On another account (and this is purely anecdotal) I believe that SQL server does a full write of the row every time anyway. If you see how triggers behave in SQL server they have an Inserted cursor and a Deleted Cursor when it does updates. Each of these cursors have the entirity of the row in them.
>
>I do know that our database techniques have been reviwed by other SQL Server Experts (MVP types) and they are OK with what we do....
>
>
>
>
>
>>>I, too, was surprised to hear Rod's approach of updating all fields all the time, but who am I to say that it's wrong? I might consider it strange, but I'm sure he'd consider some of my "best practices" as strange, too.
>>
>>You seem to be giving Rod a lot of latitude here. When I read what he said he did and how he did it in his DataClass framework, I was, frankly speaking, amazed. On the one hand, you cannot argue with his credentials but on the other hand, the thought of "doing it" like DataClass makes me shudder.