<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>The Impact of Non-Updating Updates</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx</link><description>From time to time, I encounter a system design that always issues an UPDATE against the database after a user has finished working with a record – without checking to see if any of the data was in fact altered. The prevailing wisdom seems to be that “the</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>re: The Impact of Non-Updating Updates</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx#27870</link><pubDate>Sat, 14 Aug 2010 13:36:48 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:27870</guid><dc:creator>Andy Warren</dc:creator><description>&lt;p&gt;Great post Paul, good to see it run through all the scenarios.&lt;/p&gt;</description></item><item><title>re: The Impact of Non-Updating Updates</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx#27872</link><pubDate>Sat, 14 Aug 2010 14:48:48 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:27872</guid><dc:creator>Paul White</dc:creator><description>&lt;p&gt;Thanks Andy!&lt;/p&gt;
</description></item><item><title>re: The Impact of Non-Updating Updates</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx#28612</link><pubDate>Tue, 07 Sep 2010 23:18:11 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:28612</guid><dc:creator>Marc Brooks</dc:creator><description>&lt;p&gt;Another things that is often overlooked when doing non-changing of columns is that the referential integrity will checked even when the value is not changed. &amp;nbsp;This means that &lt;/p&gt;
&lt;p&gt;UPDATE dbo.Child SET SomeColumn=@something WHERE ChildID=@someKey&lt;/p&gt;
&lt;p&gt;is going to be faster than&lt;/p&gt;
&lt;p&gt;UPDATE dbo.Child SET SomeColumn=@something, ParentID=@someParentKey WHERE ChildID=@someKey&lt;/p&gt;
&lt;p&gt;EVEN if the @someParentKey is the same value as what is currently in the row.&lt;/p&gt;
</description></item><item><title>Read Committed, Shared Locks, and Rollbacks</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx#30028</link><pubDate>Sun, 31 Oct 2010 16:19:44 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:30028</guid><dc:creator>Paul White: Page Free Space</dc:creator><description>&lt;p&gt;In this post I cover a little-known locking optimization that provides a surprising answer to the question:&lt;/p&gt;
</description></item><item><title>Beware Sneaky Reads with Unique Indexes</title><link>http://sqlblog.com/blogs/paul_white/archive/2010/08/11/the_2D00_impact_2D00_of_2D00_update_2D00_statements_2D00_that_2D00_don_2D00_t_2D00_change_2D00_data.aspx#31564</link><pubDate>Mon, 13 Dec 2010 15:34:17 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:31564</guid><dc:creator>Paul White: Page Free Space</dc:creator><description>&lt;p&gt;A few days ago, Sandra Mueller ( twitter | blog ) asked a question using twitter’s #sqlhelp hash tag:&lt;/p&gt;
</description></item></channel></rss>