20.07.2013 Views

Beginning SQL

Beginning SQL

Beginning SQL

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 11<br />

Additionally, if a DBMS is used programmatically and does not COMMIT until told to do so, it is critical that<br />

your program perform this explicit COMMIT as often as is reasonable. If you fail to do so, all the records you<br />

update (or in some instances even look at) become locked and other transactions cannot update (or in some<br />

instances even look at) any data used inside your transaction. In these environments, the rule of thumb is<br />

COMMIT early and COMMIT often.<br />

The ANSI model does not provide an explicitly defined keyword for beginning a transaction. A BEGIN<br />

TRANSACTION statement is assumed as the first statement and as the first statement following each<br />

COMMIT. This is a bit confusing and additionally does not allow the programmer to create statements<br />

that are not part of a transaction. As you see in a moment, all transactions have costs, and there are cases<br />

where transactions simply aren’t necessary. For these and other reasons, many DBMSs have added<br />

extensions to the <strong>SQL</strong> language to allow explicit BEGIN TRANSACTION statements and other enhancements.<br />

These extensions are generally known as Transact-<strong>SQL</strong>.<br />

Transact-<strong>SQL</strong><br />

Transact-<strong>SQL</strong> is an extension to the <strong>SQL</strong> syntax that some DBMSs use to allow a finer degree of control<br />

over processing transactions. In essence, whereas the ANSI standard assumes a BEGIN TRANSACTION<br />

before the first <strong>SQL</strong> statement and immediately after a COMMIT or ROLLBACK, Transact-<strong>SQL</strong> requires a<br />

BEGIN TRANSACTION statement to initiate a transaction.<br />

BEGIN TRANSACTION<br />

The BEGIN TRANSACTION statement tells the DBMS that the <strong>SQL</strong> statements that follow form a transaction<br />

group and must be processed as an atomic unit, either all processed or none processed. Unlike the<br />

ANSI transaction model, which assumes an automatic BEGIN TRANSACTION and must receive a COMMIT<br />

or a ROLLBACK statement at some point, Transact-<strong>SQL</strong> acts as if a COMMIT is performed after every <strong>SQL</strong><br />

statement unless a BEGIN TRANSACTION is processed. This is a very different model with very different<br />

results from the <strong>SQL</strong> model.<br />

COMMIT TRANSACTION<br />

308<br />

The COMMIT TRANSACTION statement is identical in function to COMMIT from the ANSI model. It causes<br />

all <strong>SQL</strong> statements since the opening BEGIN TRANSACTION to be written to the database as an atomic<br />

unit. Unlike the ANSI model, Transact-<strong>SQL</strong> does not automatically assume a new BEGIN TRANSACTION.<br />

Any <strong>SQL</strong> statements between the COMMIT TRANSACTION and the next BEGIN TRANSACTION are committed<br />

individually as they occur. Figure 11-3 shows a series of <strong>SQL</strong> statements where the first two statements<br />

are outside of any transaction. These statements are committed immediately with no opportunity<br />

to undo or roll them back. Then a BEGIN TRANSACTION is explicitly executed telling the DBMS that<br />

everything that follows should be considered part of a transaction until either a ROLLBACK or a COMMIT<br />

is encountered. In this figure, a COMMIT is executed, and at that point, the INSERT and UPDATE statements<br />

are actually saved to the disk.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!