Defensive Database Programming - Red Gate Software

Chapter 4: When UpgradingBreaks CodeIn previous chapters, we have discussed the sort of weaknesses that might exist inyour code that, if left unchecked, will undermine its consistency and reliability, andmake it vulnerable to breaking when, for example, environmental settings arechanged, or objects in the underlying schema are modified. The goal of the defensiveprogrammer is to root out as many of these weaknesses as possible and remove them,before the potential problems even arise.However, there are times when potential changes cannot be foreseen and so we cannot"weatherproof" our code against them; we cannot know in advance, for example, howuse of a new feature might affect our existing code when we do not know what thesenew features are, and how they behave.A SQL Server upgrade is always a time of concern for the applications that use it, andfor the developers of those applications. It's a time when the defensive programmermust proactively research how existing applications will behave when the new databasesettings or features are enabled, investigate how these features can be implemented inthe most robust way possible, and then revisit and revise existing code as appropriate.This chapter does not, and cannot, provide a complete list of new features in SQLServer 2005 and 2008 that could potentially break existing code. Instead, it is intendedas an eye-opener, an encouragement to analyze fully how new features work withexisting code, before using these new features in production. In order to demonstratethe difficulties that can arise, we'll discuss the following new features, both of which arehighly useful, and so are very likely to be used, but yet may break existing code:• snapshot isolation (new in 2005)• MERGE statement (new in 2008).105