<?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 : Transact SQL</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx</link><description>Tags: Transact SQL</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Yet another use of OUTER APPLY in defensive programming</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/yet-another-use-of-outer-apply-in-defensive-programming.aspx</link><pubDate>Wed, 06 Jun 2012 21:58:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:43779</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/43779.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=43779</wfw:commentRss><description>When a SELECT is used to populate variables from a subquery, it fails to change them if the subquery returns nothing - and that can lead to subtle bugs. We shall use OUTER APPLY to eliminate this problem. Prerequisites All we need is the following mock...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/yet-another-use-of-outer-apply-in-defensive-programming.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=43779" 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/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Catching multiple exceptions on the client is robust and easy</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/catching-multiple-exceptions-on-the-client-is-robust-and-easy.aspx</link><pubDate>Wed, 06 Jun 2012 17:30:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:43766</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/43766.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=43766</wfw:commentRss><description>Maria Zakourdaev has just demonstrated that if our T-SQL throws multiple exceptions, ERROR_MESSAGE() in TRY..CATCH block will only expose one. When we handle errors in C#, we have a very easy access to all errors. The following procedure throws two exceptions:...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/06/06/catching-multiple-exceptions-on-the-client-is-robust-and-easy.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=43766" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Error+Handling/default.aspx">Error Handling</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Avoiding nested transactions might not improve performance.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/08/avoiding-nested-transactions-might-not-improve-performance.aspx</link><pubDate>Wed, 08 Feb 2012 18:09:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41577</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>10</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41577.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41577</wfw:commentRss><description>Beginning a transaction only when @@TRANCOUNT=0 might not improve performance at all. At least, I did not notice any difference whatsoever. No matter if I use this pattern: BEGIN TRAN ; -- (snip) COMMIT ; or a more complex one: DECLARE @trancount INT...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/08/avoiding-nested-transactions-might-not-improve-performance.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41577" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transactions/default.aspx">Transactions</category></item><item><title>Using XACT_ABORT ON may be faster than using TRY...CATCH</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/using-xact-abort-on-may-be-faster-than-using-try-catch.aspx</link><pubDate>Wed, 01 Feb 2012 22:25:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41497</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>8</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41497.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41497</wfw:commentRss><description>To ensure atomicity of transactions, we can use XACT_ABORT ON or wrap the transaction in TRY block and rollback in CATCH block. In some cases, the XACT_ABORT ON approach uses noticeably less CPU. I am posting repro scripts. Please run them, tweak them,...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/using-xact-abort-on-may-be-faster-than-using-try-catch.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41497" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</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/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transactions/default.aspx">Transactions</category></item><item><title>Wrapping related changes in a transaction may use less CPU.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/wrapping-related-changes-in-a-transaction-may-use-less-cpu.aspx</link><pubDate>Wed, 01 Feb 2012 22:02:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41495</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>7</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41495.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41495</wfw:commentRss><description>Wrapping related changes in a transaction is a good way to ensure data integrity. Besides, in some cases it just runs noticeably faster, using less CPU. As usual, I am posting repro scripts, which you can run, tweak, and see for yourself. Environment...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/02/01/wrapping-related-changes-in-a-transaction-may-use-less-cpu.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41495" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</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/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Yet another gotcha: variables' scopes do not end where they should.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/25/yet-another-gotcha-variables-scopes-do-not-end-where-they-should.aspx</link><pubDate>Wed, 25 Jan 2012 22:09:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:41315</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>11</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/41315.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=41315</wfw:commentRss><description>Be careful: unlike most other languages, T-SQL does not limit variables' scope to the block where the variable has been defined. For example, the following snippet compiles and runs: -- @to is not in scope yet -- the line below would not compile --SET...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/25/yet-another-gotcha-variables-scopes-do-not-end-where-they-should.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=41315" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/consistency/default.aspx">consistency</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Running OLTPish system without deadlocks, and loving it.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/04/running-oltpish-system-wihtout-deadlocks-and-loving-it.aspx</link><pubDate>Wed, 04 Jan 2012 22:31:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:40808</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>9</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/40808.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=40808</wfw:commentRss><description>Our OLTPish mixed load system has not had a single deadlock since last April, and we just love it. I would not make any blanket statements, but I think in our case being deadlock-free just makes a lot of practical sense. Of course, in other cases in might...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2012/01/04/running-oltpish-system-wihtout-deadlocks-and-loving-it.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=40808" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Concurrency/default.aspx">Concurrency</category><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/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>"Trusted" Foreign Keys Allow Orphans, Reject Valid Child Rows</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/10/17/trusted-foreign-keys-allow-orphans-reject-valid-child-rows.aspx</link><pubDate>Mon, 17 Oct 2011 17:15:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:39107</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>11</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/39107.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=39107</wfw:commentRss><description>In SQL 2008 R2, MERGE does not implement foreign keys properly. I will show both false negatives (valid rows are rejected) and false positives - orphan rows that are allowed to save. False Negatives The following tables implement a very common type/subtype...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/10/17/trusted-foreign-keys-allow-orphans-reject-valid-child-rows.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=39107" width="1" height="1"&gt;</description><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/Defensive+programming/default.aspx">Defensive programming</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Preventing Bob from sales from selecting other people's messages</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/18/preventing-bob-from-sales-from-selecting-other-people-s-messages.aspx</link><pubDate>Thu, 18 Aug 2011 19:22:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:37913</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>3</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/37913.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=37913</wfw:commentRss><description>Suppose that Bob can retrieve all messages, as follows, and we are not happy with it: EXEC Exchange.ShowAllMessages ; Suppose that we don't want him to read anything related to messages, so our knee-jerk reaction is this: REVOKE EXECUTE ON Exchange.ShowAllMessages...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/18/preventing-bob-from-sales-from-selecting-other-people-s-messages.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=37913" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/SQL+Server+security/default.aspx">SQL Server security</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Reads involving UDFs under READ_COMMITTED_SNAPSHOT may seem inconsistent.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/02/reads-involving-udfs-under-read-committed-snapshot-may-seem-inconsistent.aspx</link><pubDate>Wed, 03 Aug 2011 01:33:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:37448</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>2</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/37448.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=37448</wfw:commentRss><description>When a select uses scalar or multi-statement UDFs under READ_COMMITTED_SNAPSHOT, we might not get consistent results as of the time our select began - I will provide simple repro scripts. At the time of this writing MSDN clearly states the following:...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2011/08/02/reads-involving-udfs-under-read-committed-snapshot-may-seem-inconsistent.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=37448" 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/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Math with Months Is Not Commutative</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/11/29/math-with-months-is-not-commutative.aspx</link><pubDate>Mon, 29 Nov 2010 22:58:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:31138</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>6</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/31138.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=31138</wfw:commentRss><description>In other words, if we add a month, then subtract a month, we might not get back to the date we started from. For example: SELECT DATEADD ( MONTH , 1 , DATEADD ( MONTH , - 1 , '20100330' )) , DATEADD ( MONTH , - 1 , DATEADD ( MONTH , 1 , '20100330' ))...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/11/29/math-with-months-is-not-commutative.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=31138" 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/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Benefit from Unit Testing T-SQL: Ensure quick turnaround</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/11/03/benefit-from-unit-testing-t-sql-ensure-quick-turnaround.aspx</link><pubDate>Thu, 04 Nov 2010 01:50:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:30153</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>0</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/30153.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=30153</wfw:commentRss><description>The biggest advantage of unit testing is the ability to make changes quickly, and with confidence that we have not broken anything with our change. Whether we need to speed up a query real quick, or to fix a bug, automated testing saves us a lot of time,...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/11/03/benefit-from-unit-testing-t-sql-ensure-quick-turnaround.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=30153" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Database+Unit+Testing/default.aspx">Database Unit Testing</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Unit+testing/default.aspx">Unit testing</category></item><item><title>Myth Busting: COUNT(*) under REPEATABLE READ may return wrong results</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/21/myth-busting-count-under-repeatable-read-may-return-wrong-results.aspx</link><pubDate>Thu, 21 Oct 2010 16:04:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:29597</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>15</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/29597.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=29597</wfw:commentRss><description>This came up on sqlservercentral.com, where I read the following claim (in a discussion thread, not in an article): " COUNT(*) is only guaranteed accurate if your isolation level is REPEATABLE READ, SERIALIZABLE, or SNAPSHOT ". I have a repro script which...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/21/myth-busting-count-under-repeatable-read-may-return-wrong-results.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=29597" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Myth+Busting/default.aspx">Myth Busting</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>Uncertainty erodes confidence, so add that ORDER BY clause.</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/18/uncertainty-erodes-confidence-so-add-that-order-by-clause.aspx</link><pubDate>Mon, 18 Oct 2010 18:18:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:29457</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>4</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/29457.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=29457</wfw:commentRss><description>I was reading Eric Lippert's blog post , and came across the following quote: "uncertainty erodes confidence in our users that we have a quality product that was designed with deep thought, implemented with care, and behaves predictably and sensibly"....(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/18/uncertainty-erodes-confidence-so-add-that-order-by-clause.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=29457" width="1" height="1"&gt;</description><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Best+Practices/default.aspx">Best Practices</category><category domain="http://sqlblog.com/blogs/alexander_kuznetsov/archive/tags/Transact+SQL/default.aspx">Transact SQL</category></item><item><title>My book is complete, many thanks to Hugo, Tony, and many others!</title><link>http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/06/18/my-book-is-complete-many-thanks-to-hugo-tony-and-many-others.aspx</link><pubDate>Fri, 18 Jun 2010 19:22:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:26267</guid><dc:creator>Alexander Kuznetsov</dc:creator><slash:comments>12</slash:comments><comments>http://sqlblog.com/blogs/alexander_kuznetsov/comments/26267.aspx</comments><wfw:commentRss>http://sqlblog.com/blogs/alexander_kuznetsov/commentrss.aspx?PostID=26267</wfw:commentRss><description>My book is finished. A couple years ago I googled up "Defensive Database Programming", and came up with nothing. Naturally, I started filling up the void. Although the book is complete, I am planning to continue my research; I would appreciate any other...(&lt;a href="http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/06/18/my-book-is-complete-many-thanks-to-hugo-tony-and-many-others.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://sqlblog.com/aggbug.aspx?PostID=26267" 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/Transact+SQL/default.aspx">Transact SQL</category></item></channel></rss>