Назад в раздел
Table 11.2. The BALANCES table.
Assume now that your application program performs a SELECT operation and retrieves the following data for Bill Turner: OUTPUT:NAME: Bill Turner ADDRESS: 725 N. Deal Parkway CITY: Washington STATE: DC ZIP: 20085 CUSTOMER_ID: 1 While this information is being retrieved, another user with a connection to this database updates Bill Turner's address information: INPUT:SQL> UPDATE CUSTOMERS SET Address = "11741 Kingstowne Road"
WHERE Name = "Bill Turner";
As you can see, the information you retrieved earlier could be invalid if the update occurred during the middle of your SELECT. If your application fired off a letter to be sent to Mr. Bill Turner, the address it used would be wrong. Obviously, if the letter has already been sent, you won't be able to change the address. However, if you had used a transaction, this data change could have been detected, and all your other operations could have been rolled back. Beginning a TransactionTransactions are quite simple to implement. You will examine the syntax used to perform transactions using the Oracle RDBMS SQL syntax as well as the Sybase SQL Server SQL syntax. All database systems that support transactions must have a way to explicitly tell the system that a transaction is beginning. (Remember that a transaction is a logical grouping of work that has a beginning and an end.) Using Personal Oracle7, the syntax looks like this: SYNTAX:SET TRANSACTION {READ ONLY | USE ROLLBACK SEGMENT segment}
The SQL standard specifies that each database's SQL implementation must support statement-level read consistency; that is, data must stay consistent while one statement is executing. However, in many situations data must remain valid across a single unit of work, not just within a single statement. Oracle enables the user to specify when the transaction will begin by using the SET TRANSACTION statement. If you wanted to examine Bill Turner's information and make sure that the data was not changed, you could do the following: INPUT:SQL> SET TRANSACTION READ ONLY;
SQL> SELECT * FROM CUSTOMERS
WHERE NAME = 'Bill Turner';
---Do Other Operations---
SQL> COMMIT;
We discuss the COMMIT statement later today. The SET TRANSACTION READ ONLY option enables you to effectively lock a set of records until the transaction ends. You can use the READ ONLY option with the following commands: SELECT LOCK TABLE SET ROLE ALTER SESSION ALTER SYSTEM
SQL Server's Transact-SQL language implements the BEGIN TRANSACTION command with the following syntax: SYNTAX:begin {transaction | tran} [transaction_name]
This implementation is a little different from the Oracle implementation. (Sybase does not allow you to specify the READ ONLY option.) However, Sybase does allow you to give a transaction a name, as long as that transaction is the outermost of a set of nested transactions. The following group of statements illustrates the use of nested transactions using Sybase's Transact-SQL language: INPUT:1> begin transaction new_account
2> insert CUSTOMERS values ("Izetta Parsons", "1285 Pineapple Highway", "Greenville", "AL" 32854, 6)
3> if exists(select * from CUSTOMERS where Name = "Izetta Parsons")
4> begin
5> begin transaction
6> insert BALANCES values(1250.76, 1431.26, 8)
7> end
8> else
9> rollback transaction
10> if exists(select * from BALANCES where Account_ID = 8)
11> begin
12> begin transaction
13> insert ACCOUNTS values(8, 6)
14> end
15> else
16> rollback transaction
17> if exists (select * from ACCOUNTS where Account_ID = 8 and Customer_ID = 6)
18> commit transaction
19> else
20> rollback transaction
21> go
For now, don't worry about the ROLLBACK TRANSACTION and COMMIT TRANSACTION statements. The important aspect of this example is the nested transaction--or a transaction within a transaction. Notice that the original transaction (new_account) begins on line 1. After the first insert, you check to make sure the INSERT was executed properly. Another transaction begins on line 5. This transaction within a transaction is termed a nested transaction. Other databases support the AUTOCOMMIT option. This option can be used with the SET command. For example: SET AUTOCOMMIT [ON | OFF] By default, the SET AUTOCOMMIT ON command is executed at startup. It tells SQL to automatically commit all statements you execute. If you do not want these commands to be automatically executed, set the AUTOCOMMIT option to off: SET AUTOCOMMIT OFF
Finishing a TransactionThe Oracle syntax to end a transaction is as follows: SYNTAX:COMMIT [WORK] [ COMMENT 'text' | FORCE 'text' [, integer] ] ; Here is the same command using Sybase syntax: SYNTAX:COMMIT (TRANSACTION | TRAN | WORK) (TRANSACTION_NAME) The COMMIT command saves all changes made during a transaction. Executing a COMMIT statement before beginning a transaction ensures that no errors were made and no previous transactions are left hanging. The following example verifies that the COMMIT command can be used by itself without receiving an error back from the database system. INPUT:SQL> COMMIT;
SQL> SET TRANSACTION READ ONLY;
SQL> SELECT * FROM CUSTOMERS
WHERE NAME = 'Bill Turner';
---Do Other Operations---
SQL> COMMIT;
An Oracle SQL use of the COMMIT statement would look like this: INPUT:SQL> SET TRANSACTION;
SQL> INSERT INTO CUSTOMERS VALUES
("John MacDowell", "2000 Lake Lunge Road", "Chicago", "IL", 42854, 7);
SQL> COMMIT;
SQL> SELECT * FROM CUSTOMERS;
The CUSTOMERS table.
A Sybase SQL use of the COMMIT statement would look like this: INPUT:1> begin transaction
2> insert into CUSTOMERS values
("John MacDowell", "2000 Lake Lunge Road", "Chicago", "IL", 42854, 7)
3> commit transaction
4> go
1> select * from CUSTOMERS
2> go
The CUSTOMERS table.
The preceding statements accomplish the same thing as they do using the Oracle7 syntax. However, by putting the COMMIT command soon after the transaction begins, you ensure that the new transaction will execute correctly.
Remember that every COMMIT command must correspond with a previously executed SET TRANSACTION or BEGIN TRANSACTION command. Note the errors you receive with the following statements: Oracle SQL: INPUT:SQL> INSERT INTO BALANCES values (18765.42, 19073.06, 8); SQL> COMMIT WORK; Sybase SQL: INPUT:1> insert into BALANCES values (18765.42, 19073.06, 8) 2> commit work Canceling the TransactionWhile a transaction is in progress, some type of error checking is usually performed to determine whether it is executing successfully. You can undo your transaction even after successful completion by issuing the ROLLBACK statement, but it must be issued before a COMMIT. The ROLLBACK statement must be executed from within a transaction. The ROLLBACK statement rolls the transaction back to its beginning; in other words, the state of the database is returned to what it was at the transaction's beginning. The syntax for this command using Oracle7 is the following: SYNTAX:ROLLBACK [WORK] [ TO [SAVEPOINT] savepoint | FORCE 'text' ] As you can see, this command makes use of a transaction savepoint. We discuss this technique later today. Sybase Transact-SQL's ROLLBACK statement looks very similar to the COMMIT command: SYNTAX:rollback {transaction | tran | work}
[transaction_name | savepoint_name]
An Oracle SQL sequence of commands might look like this: INPUT:SQL> SET TRANSACTION;
SQL> INSERT INTO CUSTOMERS VALUES
("Bubba MacDowell", "2222 Blue Lake Way", "Austin", "TX", 39874, 8);
SQL> ROLLBACK;
SQL> SELECT * FROM CUSTOMERS;
The CUSTOMERS table.
A Sybase SQL sequence of commands might look like this: INPUT:1> begin transaction
2> insert into CUSTOMERS values
("Bubba MacDowell", "2222 Blue Lake Way", "Austin", "TX", 39874, 8)
3> rollback transaction
4> go
1> SELECT * FROM CUSTOMERS
2> go
The CUSTOMERS table.
As you can see, the new record was not added because the ROLLBACK statement rolled the insert back. Suppose you are writing an application for a graphical user interface, such as Microsoft Windows. You have a dialog box that queries a database and allows the user to change values. If the user chooses OK, the database saves the changes. If the user chooses Cancel, the changes are canceled. Obviously, this situation gives you an opportunity to use a transaction.
When the dialog box is loaded, these SQL statements are executed: INPUT:SQL> SET TRANSACTION; SQL> SELECT CUSTOMERS.NAME, BALANCES.CURR_BAL, BALANCES.ACCOUNT_ID 2 FROM CUSTOMERS, BALANCES 3 WHERE CUSTOMERS.NAME = "Rebecca Little" 4 AND CUSTOMERS.CUSTOMER_ID = BALANCES.ACCOUNT_ID; The dialog box allows the user to change the current account balance, so you need to store this value back to the database. When the user selects OK, the update will run. INPUT:SQL> UPDATE BALANCES SET CURR_BAL = 'new-value' WHERE ACCOUNT_ID = 6; SQL> COMMIT; When the user selects Cancel, the ROLLBACK statement is issued. INPUT:SQL> ROLLBACK; When the dialog box is loaded using Sybase SQL, these SQL statements are executed: INPUT:1> begin transaction 2> select CUSTOMERS.Name, BALANCES.Curr_Bal, BALANCES.Account_ID 3> from CUSTOMERS, BALANCES 4> where CUSTOMERS.Name = "Rebecca Little" 5> and CUSTOMERS.Customer_ID = BALANCES.Account_ID 6> go The dialog box allows the user to change the current account balance, so you can store this value back to the database. Here again, when the OK button is selected, the update will run. INPUT:1> update BALANCES set Curr_BAL = 'new-value' WHERE Account_ID = 6 2> commit transaction 3> go When the user selects Cancel, the ROLLBACK statement is issued. INPUT:1> rollback transaction 2> go The ROLLBACK statement cancels the entire transaction. When you are nesting transactions, the ROLLBACK statement completely cancels all the transactions, rolling them back to the beginning of the outermost transaction. If no transaction is currently active, issuing the ROLLBACK statement or the COMMIT command has no effect on the database system. (Think of them as dead commands with no purpose.) After the COMMIT statement has been executed, all actions with the transaction are executed. At this point it is too late to roll back the transaction. Using Transaction SavepointsRolling back a transaction cancels the entire transaction. But suppose you want to "semicommit" your transaction midway through its statements. Both Sybase and Oracle SQL allow you to save the transaction with a savepoint. From that point on, if a ROLLBACK is issued, the transaction is rolled back to the savepoint. All statements that were executed up to the point of the savepoint are saved. The syntax for creating a savepoint using Oracle SQL is as follows: SYNTAX:SAVEPOINT savepoint_name; Sybase SQL Server's syntax to create a savepoint is the following: SYNTAX:save transaction savepoint_name This following example uses Oracle SQL syntax. INPUT:SQL> SET TRANSACTION; SQL> UPDATE BALANCES SET CURR_BAL = 25000 WHERE ACCOUNT_ID = 5; SQL> SAVEPOINT save_it; SQL> DELETE FROM BALANCES WHERE ACCOUNT_ID = 5; SQL> ROLLBACK TO SAVEPOINT save_it; SQL> COMMIT; SQL> SELECT * FROM BALANCES; The BALANCES table.
This example uses Sybase SQL syntax: INPUT:1> begin transaction 2> update BALANCES set Curr_Bal = 25000 where Account_ID = 5 3> save transaction save_it 4> delete from BALANCES where Account_ID = 5 5> rollback transaction save_it 6> commit transaction 7> go 1> select * from BALANCES 2> go The BALANCES table.
The previous examples created a savepoint called SAVE_IT. An update was made to the database that changed the value of the CURR_BAL column of the BALANCES table. You then saved this change as a savepoint. Following this save, you executed a DELETE statement, but you rolled the transaction back to the savepoint immediately thereafter. Then you executed COMMIT TRANSACTION, which committed all commands up to the savepoint. Had you executed a ROLLBACK TRANSACTION after the ROLLBACK TRANSACTION savepoint_name command, the entire transaction would have been rolled back and no changes would have been made. This example uses Oracle SQL syntax: INPUT:SQL> SET TRANSACTION; SQL> UPDATE BALANCES SET CURR_BAL = 25000 WHERE ACCOUNT_ID = 5; SQL> SAVEPOINT save_it; SQL> DELETE FROM BALANCES WHERE ACCOUNT_ID = 5; SQL> ROLLBACK TO SAVEPOINT save_it; SQL> ROLLBACK; SQL> SELECT * FROM BALANCES; The BALANCES table.
This example uses Sybase SQL syntax: INPUT:1> begin transaction 2> update BALANCES set Curr_Bal = 25000 where Account_ID = 5 3> save transaction save_it 4> delete from BALANCES where Account_ID = 5 5> rollback transaction save_it 6> rollback transaction 7> go 1> select * from BALANCES 2> go The BALANCES table.
SummaryA transaction can be defined as an organized unit of work. A transaction usually performs a series of operations that depend on previously executed operations. If one of these operations is not executed properly or if data is changed for some reason, the rest of the work in a transaction should be canceled. Otherwise, if all statements are executed correctly, the transaction's work should be saved. The process of canceling a transaction is called a rollback. The process of saving the work of a correctly executed transaction is called a commit. SQL syntax supports these two processes through syntax similar to the following two statements: SYNTAX:BEGIN TRANSACTION
statement 1
statement 2
statement 3
ROLLBACK TRANSACTION
or SYNTAX:BEGIN TRANSACTION
statement 1
statement 2
statement 3
COMMIT TRANSACTION
Q&A
WorkshopThe Workshop provides quiz questions to help solidify your understanding of the material covered, as well as exercises to provide you with experience in using what you have learned. Try to answer the quiz and exercise questions before checking the answers in Appendix F, "Answers to Quizzes and Exercises." Quiz
Exercises
   
© Copyright, Macmillan Computer Publishing. All rights reserved. |
 |
|
