<?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>Alexander Kuznetsov : SQL Server</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx</link><description>Tags: SQL Server</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Five Years of Writing about SQL Server</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/19/five-years-of-writing-about-sql-server.aspx</link><pubDate>Tue, 19 Oct 2010 19:30:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:29504</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/29504.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=29504</wfw:commentRss><description>Five years ago I published my first article about SQL Server, "Index Covering Boosts SQL Server Query Performance" It is still quite popular - I just googled up "index covering", and it comes right on top. Bing does the same thing. It was just mentioned...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/19/five-years-of-writing-about-sql-server.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=29504" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Index+Covering/default.aspx">Index Covering</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Book Review: Oracle Database Administration for Microsoft SQL Server DBAs</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/27/book-review-oracle-database-administration-for-microsoft-sql-server-dbas.aspx</link><pubDate>Mon, 27 Sep 2010 18:26:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:29003</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>3</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/29003.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=29003</wfw:commentRss><description>Working in mixed database environments is a very interesting challenge, both for DBAs and developers. If we already have experience with SQL Server, and need to work with Oracle, our SQL Server experience may be an advantage - we already have a good handle...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/27/book-review-oracle-database-administration-for-microsoft-sql-server-dbas.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=29003" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Book+Review/default.aspx">Book Review</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Oracle/default.aspx">Oracle</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Additional links for my presentation on defensive database programming.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/19/additional-links-for-my-presentation-on-defensive-database-programming.aspx</link><pubDate>Sun, 19 Sep 2010 18:29:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:28859</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>1</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/28859.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=28859</wfw:commentRss><description>Yesterday I delivered a session named "Develop T-SQL defensively" at East Iowa SQL Saturday. Thanks to those who attended, and many thanks to Michelle Ufford, Chris Leonard, Ed Leighton-Dick, and other volunteers, who organized the event. Here are the...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/19/additional-links-for-my-presentation-on-defensive-database-programming.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=28859" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Saturday/default.aspx">SQL Saturday</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Repro scripts and more info for my presentation on concurrency</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/19/repro-scripts-and-more-info-for-my-presentation-on-concurrency.aspx</link><pubDate>Sun, 19 Sep 2010 18:10:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:28858</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>0</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/28858.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=28858</wfw:commentRss><description>Yesterday I delivered a session named "Developing T-SQL to survive concurrency" at East Iowa SQL Saturday. Thanks to everyone who attended, and thanks to Michelle Ufford, Chris Leonard, Ed Leighton-Dick, and other volunteers, who organized the event....(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/09/19/repro-scripts-and-more-info-for-my-presentation-on-concurrency.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=28858" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Deadlocks/default.aspx">SQL Deadlocks</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Saturday/default.aspx">SQL Saturday</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Using CROSS APPLY to optimize joins on BETWEEN conditions</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/07/07/using-cross-apply-to-optimize-joins-on-between-conditions.aspx</link><pubDate>Wed, 08 Jul 2009 00:47:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:15148</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>19</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/15148.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=15148</wfw:commentRss><description>Recently I encountered a case when I knew much more about the data than the optimizer. Originally the performance was horrible, this is why I had to have a look at the query in the first place. When I was able to share my knowledge with the optimizer,...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/07/07/using-cross-apply-to-optimize-joins-on-between-conditions.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=15148" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/query+performance/default.aspx">query performance</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Without ORDER BY, there is no default sort order.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/20/without-order-by-there-is-no-default-sort-order.aspx</link><pubDate>Wed, 20 May 2009 13:31:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:14172</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>19</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/14172.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=14172</wfw:commentRss><description>Sounds trivial? Right, but different flavors of this myth still persist. Yesterday I noticed a thread on stackoverflow discussing SELECT TOP without a where clause, where it was suggested that "The order will be defined based on the clustered key in that...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/20/without-order-by-there-is-no-default-sort-order.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=14172" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQLL+Myths/default.aspx">SQLL Myths</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Your TRY block may fail, and your CATCH block may be bypassed.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/13/your-try-block-may-fail-and-your-catch-block-may-be-bypassed.aspx</link><pubDate>Thu, 14 May 2009 01:11:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:14032</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>10</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/14032.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=14032</wfw:commentRss><description>Some T-SQL code is written under the assumption that either a TRY block successfully completes or a CATCH block is invoked. Most likely, this is the case. However, there is a third, although rare, possibility – the TRY block may fail, and the CATCH one...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/13/your-try-block-may-fail-and-your-catch-block-may-be-bypassed.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=14032" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Two suggestions to enhance constraints in SQL Server</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/04/two-suggestions-to-enhance-constraints-in-sql-server.aspx</link><pubDate>Tue, 05 May 2009 03:29:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:13770</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>4</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/13770.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=13770</wfw:commentRss><description>We can tuck any logical expressions in CHECK constraints, but all foreign keys are currently capable of right now is to verify that one or more column values are equal. In many cases it would be very useful to have foreign keys use more complex logical...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/05/04/two-suggestions-to-enhance-constraints-in-sql-server.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=13770" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Business+rules/default.aspx">Business rules</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Data+Integrity/default.aspx">Data Integrity</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Using ROWVERSION to enforce business rules</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/28/using-rowversion-to-enforce-business-rules.aspx</link><pubDate>Wed, 29 Apr 2009 02:46:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:13620</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/13620.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=13620</wfw:commentRss><description>Suppose that you need to enforce the following business rule: contracts cannot be changed after you have started working on them (let us assume that that particular business operates in the perfect world). You can use a ROWVERSION column, a persisted...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/28/using-rowversion-to-enforce-business-rules.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=13620" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Business+rules/default.aspx">Business rules</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>When you process your rows one by one, avoid infinite loops</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/23/when-you-process-your-rows-one-by-one-avoid-infinite-loops.aspx</link><pubDate>Fri, 24 Apr 2009 02:57:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:13490</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>1</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/13490.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=13490</wfw:commentRss><description>When you process your rows one by one in a loop, you need to make sure that your loop never runs infinitely. I will describe three scenarios with possible infinite loops. There have been many articles discussing feasibility of loops vs. set-based solutions...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/23/when-you-process-your-rows-one-by-one-avoid-infinite-loops.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=13490" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Infinite+loops/default.aspx">Infinite loops</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Avoiding infinite loops. Part One.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/20/avoiding-infinite-loops-part-one.aspx</link><pubDate>Tue, 21 Apr 2009 03:11:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:13407</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/13407.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=13407</wfw:commentRss><description>Although there are many discussions about which kind of cursor or loop performs the best, there is no doubt which loops perform the worst – the infinite ones of course. Whenever you write a loop, you need to make sure that it never runs infinitely. I...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/20/avoiding-infinite-loops-part-one.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=13407" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Infinite+loops/default.aspx">Infinite loops</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Selects under READ COMMITTED and REPEATABLE READ may return incorrect results.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/10/selects-under-read-committed-and-repeatable-read-may-return-incorrect-results.aspx</link><pubDate>Sat, 11 Apr 2009 00:34:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:13217</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>14</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/13217.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=13217</wfw:commentRss><description>Selects under READ COMMITTED may return incorrect results if the data they select is being modified at the same time. I will provide a repro script which on my laptop returns incorrect results in more than 90% cases. Also I will provide a similar repro...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/04/10/selects-under-read-committed-and-repeatable-read-may-return-incorrect-results.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=13217" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Deadlocks/default.aspx">SQL Deadlocks</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Reproducing one more intermittent deadlock on only one table</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/26/reproducing-one-more-intermittent-deadlock-on-only-one-table.aspx</link><pubDate>Thu, 26 Mar 2009 15:46:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:12943</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/12943.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=12943</wfw:commentRss><description>I have already described several deadlock scenarios that involve only one table in another post. This time I will describe an intermittent deadlock which occurs in high concurrency environments. Before providing a complex repro script for it, I will provide...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/26/reproducing-one-more-intermittent-deadlock-on-only-one-table.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=12943" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Deadlocks/default.aspx">Deadlocks</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Deadlocks/default.aspx">SQL Deadlocks</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category></item><item><title>Defensive database programming: fun with ROWCOUNT</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/21/defensive-database-programming-fun-with-rowcount.aspx</link><pubDate>Sun, 22 Mar 2009 02:59:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:12838</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/12838.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=12838</wfw:commentRss><description>I have written up two examples when a SET ROWCOUNT command breaks a seemingly working stored procedure or trigger. Note that currently the best practice is to use TOP clause instead of SET ROWCOUNT, which is deprecated in SQL Server 2008. However, even...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/21/defensive-database-programming-fun-with-rowcount.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=12838" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Programming/default.aspx">Database Programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Some heap tables may be more prone to deadlocks than identical tables with clustered indexes</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/11/some-heap-tables-may-be-more-prone-to-deadlocks-than-identical-tables-with-clustered-indexes.aspx</link><pubDate>Thu, 12 Mar 2009 03:05:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:12576</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>31</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/12576.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=12576</wfw:commentRss><description>Apparently for high isolation levels some heap tables may be more prone to deadlocks than identical tables with clustered indexes. I have a simple repro script which successfully completes if a table has a clustered index but embraces in a deadlock if...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/03/11/some-heap-tables-may-be-more-prone-to-deadlocks-than-identical-tables-with-clustered-indexes.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=12576" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Deadlock/default.aspx">Deadlock</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server/default.aspx">SQL Server</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item></channel></rss>