Changing What Is Already Stored

You alter data through the use of UPDATE. Just as with the input of data, any alterations made to the data are subject to the rules and constraints defined in the table schema. Any data modifications made that do not meet these defined standards result in errors that the front-end application may have to trap and control.

Updating a Single Record

There are three different techniques for updating a single record:

• Filtered update This technique is no different than changing a number of records. The difference is that the criteria used need to be something unique, such as a primary key or an identity.

• Positioned update This technique is a programmatic solution. Essentially, you set up a procedure that scrolls through the data. When the record pointer (that is, cursor) is on the record to be updated, you issue the UPDATE command with the WHERE CURRENT OF clause.

• Computed column You can update a single record by using a computed column. In this case, when the computation involves a field whose value changes, the result of the computation is affected and the field will change.

Doing Updates That Affect Multiple Records

Most data modifications are based on a conditional operation or are in-place updates of the current record. The following is a basic UPDATE statement that adjusts data based on the criteria given:

UPDATE Customers   SET Region = 'South America'   WHERE Country IN ('Argentina', 'Brazil', 'Venezuela') 

Obviously, an update performed with a broad condition will affect a number of records. Records in other tables could be affected. In the event of cascading updates, if a referenced row has its key altered, those changes would ripple down to the related rows of the subsidiary table.

Performing Transaction Processing

Updating data within a transaction gives you a chance to undo changes before they are actually saved to the database. This usually comes into play when there are a number of steps needed for the data alteration to be valid. If any of the steps within the process fails, you can roll back everything that has been done, which leaves the system as if no change had ever occurred.

The key to handling transactions is to know when to commit the change and when to roll it back. You usually execute the ROLLBACK statement as part of a conditional operation that checks for lack of success in the process. If an error occurs in a transaction, you roll back the transaction. If the user decides to cancel the transaction, you roll back the transaction. If a portion of a required process cannot be completed, you roll back the transaction.

A ROLLBACK statement backs out all modifications made in the transaction. This statement returns the data to the state it was in at the start of the transaction. When errors occur, you should use COMMIT or ROLLBACK. You use COMMIT if you want to ensure that changes are saved to the point of the error, and you use ROLLBACK to cancel all changes.

One effective tool for handling errors, including those in transactions, is the new T-SQL TRY/CATCH construct, illustrated here:

BEGIN TRY     -- Attempt the desired processing     COMMIT END TRY BEGIN CATCH     -- An error occurred, handle it or     ROLLBACK END CATCH; GO 

Normally, ROLLBACK would occur during the CATCH operation; however, if desired, a COMMIT could be coded there as well to save the changes instead of abandoning the operation.

Upgrading Data from Previous Releases of SQL Server

If you have worked with SQL Server for a while and are comfortable with the four-part naming convention for addressing objects, you will be comfortable working with the new object schemas, which also uses a four-part name for addressing objects:

Server.Catalog.Schema.Object 

The Schema portion historically was addressed as the object owner. All objects on previous instances of the server were generally owned by dbo. That makes the most common schema for upgraded databases the dbo schema. For comparison purposes, you can visit the Microsoft website, at www.microsoft.com/sql/downloads/2005/default.mspx, and install the sample databases Pubs, Northwind, and AdventureWorks and compare the object naming conventions.