Alexander Kuznetsov : Defensive programming, Transact SQL

Yet another use of OUTER APPLY in defensive programming

Alexander Kuznetsov — Wed, 06 Jun 2012 21:58:00 GMT

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...(read more)

"Trusted" Foreign Keys Allow Orphans, Reject Valid Child Rows

Alexander Kuznetsov — Mon, 17 Oct 2011 17:15:00 GMT

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...(read more)

Reads involving UDFs under READ_COMMITTED_SNAPSHOT may seem inconsistent.

Alexander Kuznetsov — Wed, 03 Aug 2011 01:33:00 GMT

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:...(read more)

Math with Months Is Not Commutative

Alexander Kuznetsov — Mon, 29 Nov 2010 22:58:00 GMT

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' ))...(read more)

My book is complete, many thanks to Hugo, Tony, and many others!

Alexander Kuznetsov — Fri, 18 Jun 2010 19:22:00 GMT

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...(read more)

Yet another example of defensive query optimization

Alexander Kuznetsov — Thu, 18 Feb 2010 20:11:00 GMT

My second take at the same problem I blogged about yesterday: To optimize a query, we frequently have to explicitly tell optimizer some information which it does not realize by itself. Short term, this works, but long term we run the risk that what we...(read more)

Optimizing a query, then documenting assumptions in a unit test.

Alexander Kuznetsov — Wed, 17 Feb 2010 22:02:00 GMT

To optimize a query, we frequently have to explicitly tell optimizer some information which it does not realize by itself. Short term, this works, but long term we run the risk that what we are telling to the optimizer may be no longer relevant. This...(read more)

Don't swap horses in midstream.

Alexander Kuznetsov — Mon, 01 Feb 2010 19:07:00 GMT

We can begin a transaction under snapshot isolation, but we cannot switch to it in the middle of an outstanding transaction. For example, the following procedure looks good and passes a smoke test: CREATE PROCEDURE dbo.SelectCountry @CountrySymbol CHAR...(read more)

When acquiring locks in the same order is not possible or not feasible.

Alexander Kuznetsov — Fri, 15 Jan 2010 21:18:00 GMT

To avoid deadlocks, one of the most common recommendations is "to acquire locks in the same order" or "access objects in the same order". Clearly this makes perfect sense, but is it always feasible? Is it always possible? I keep encountering cases when...(read more)

T-SQL Tuesday #002: patterns that do not work as expected.

Alexander Kuznetsov — Tue, 12 Jan 2010 14:38:00 GMT

Neither UPDATE … IF (@@ROWCOUNT = 0) INSERT nor IF EXISTS(...) UPDATE ELSE INSERT patterns work as expected under high concurrency. Both may fail. Both may fail very frequently. MERGE is the king - it holds up much better.Let us do some stress testing...(read more)

Your TRY block may fail, and your CATCH block may be bypassed.

Alexander Kuznetsov — Thu, 14 May 2009 01:11:00 GMT

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...(read more)

Avoiding infinite loops. Part One.

Alexander Kuznetsov — Tue, 21 Apr 2009 03:11:00 GMT

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...(read more)

Defensive database programming: fun with ROWCOUNT

Alexander Kuznetsov — Sun, 22 Mar 2009 02:59:00 GMT

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...(read more)

Summarizing previous posts about defensive database programming

Alexander Kuznetsov — Mon, 09 Mar 2009 01:33:00 GMT

I have been posting examples of defensive database programming for some time now. I am by no means done with this topic, there is much more to it. Yet this time I would like to skip concrete examples and write up a long overdue introduction. Defensive...(read more)

Defensive database programming: SET vs. SELECT.

Alexander Kuznetsov — Sun, 25 Jan 2009 18:40:00 GMT

Comparing SET vs. SELECT is a very popular topic, and much of what I have to say has been said before. Assigning multiple values via SELECT performs better , and you don’t have to repeat your code several times, as described by Tony Rogerson here and...(read more)