Tài liệu Using SQL phần 4 doc

Removing Rows From a Table
You use the DELETE statement to remove rows from a table. When removing a row, you
specify the name of the table and the rows to delete using a WHERE clause.
Warning If you omit the WHERE clause in a DELETE statement, all rows from the table
will be deleted. Make sure you provide a WHERE clause if you don't want to
remove all the rows from the table. Typically, you'll specify the value for the
primary key in your WHERE clause.
The following DELETE statement removes the row from the Customers table where the
CustomerID is CRCOM:
DELETE FROM Customers
WHERE CustomerID = 'CRCOM';
Figure 3.24
shows this DELETE statement, along with a SELECT statement that
demonstrates that the row has been removed.

Figure 3.24: Using an UPDATE statement to remove a row from the Customers table
In the next section
, you'll learn how the database software maintains the integrity of the
information stored in the database.
Maintaining Database Integrity
The database software ensures that the information stored in the tables is consistent. In
technical terms, it maintains the integrity of the information. Two examples of this are the
following:
•
The primary key of a row always contains a unique value.
•
The foreign key of a row in the child table always references a value that exists in
the parent table.
Let's take a look at what happens when you try to insert a row into a table with a primary
key that already exists. The following INSERT statement attempts to add a row to the
Customers table with a CustomerID of ALFKI (a row with this primary key already

exists in the Customers table):
INSERT INTO Customers (
CustomerID, CompanyName, ContactName, ContactTitle, Address,
City, Region, PostalCode, Country, Phone, Fax
) VALUES (
'ALFKI', 'Jason Price Company', 'Jason Price', 'Owner', '1 Main Street',
'New York', NULL, '12345', 'USA', '(800)-555-1212', NULL
);

If you attempt to run this INSERT statement, you'll get the following error message from
the database:
Violation of PRIMARY KEY constraint 'PK_Customers'.
Cannot insert duplicate key in object 'Customers'.
The statement has been terminated.
This INSERT statement fails because an existing row in Customers table already contains
the primary key value ALFKI. The message tells you that the primary key specified in the
INSERT statement already exists in the Customers table. The constraint name
PK_Customers is the name of the table constraint assigned to the primary key when the
Customers table was originally created. At the end, the message indicates that the
statement has been terminated, meaning that the INSERT statement has not been
performed.
Let's take a look at what happens when you try to modify a primary key in a parent table
with a value that is referenced in a foreign key in a child table. The following UPDATE
statement attempts to modify the CustomerID from ALFKI to ALFKZ in the parent
Customers table (this row is referenced by rows in the child Orders table):
UPDATE Customers
SET CustomerID = 'ALFKZ'
WHERE CustomerID = 'ALFKI';
If you attempt to run this UPDATE statement, you'll get the following error message:
UPDATE statement conflicted with COLUMN REFERENCE constraint

'FK_Orders_Customers'. The conflict occurred in database
'Northwind', table 'Orders', column 'CustomerID'.
The statement has been terminated.
This UPDATE statement fails because the row containing the primary key value ALFKI
is referenced by rows in the Orders table. The message tells you that the new value for
the CustomerID column violates the foreign key constraint on the CustomerID column of
the Orders table. This constraint is named FK_Orders_Customers.
Also, you can't remove a row from a parent table that is referenced by a row in a child
table. For example, the following DELETE statement attempts to remove the row from
the Customers table where the CustomerID column equals ALFKI (this row is referenced
by rows in the Orders table):
DELETE FROM Customers
WHERE CustomerID = 'ALFKI';
If you attempt to run this DELETE statement, you'll get the same error message that was
shown for the previous UPDATE statement. This DELETE statement fails because the
Orders table contains rows that reference the row in the Customers table, and removing
this row would make the database inconsistent because the rows in the Orders table
wouldn't reference a valid row.
Grouping SQL Statements
By default, when you run an INSERT, UPDATE, or DELETE statement, SQL Server
permanently records the results of the statement in the database. This might not always be
your desired result. For example, in the case of a banking transaction, you might want to
withdraw money from one account and deposit it into another. If you had two separate
UPDATE statements that performed the withdrawal and deposit, then you would want to
make the results of each UPDATE statement permanent only as one unit. If either
UPDATE failed for some reason, then you would want to undo the results of both
UPDATE statements.

Note Permanently recording the results of SQL statements is known as a commit, or
committing the SQL statements. Undoing the results of SQL statements is known as

a rollback, or rolling back the SQL statements.
You can group SQL statements into a transaction. You can then commit or roll back the
SQL statements in that transaction as one unit. For example, the two UPDATE
statements in the previous banking example could be placed into a transaction, and then
you could commit or roll back that transaction as one unit, depending on whether both of
the UPDATE statements succeeded.
You start a transaction using the BEGIN TRANSACTION statement or the shorthand
version, BEGIN TRANS. You then perform your SQL statements that make up the
transaction. To commit the transaction, you perform a COMMIT TRANSACTION
statement or one of the shorthand versions, COMMIT TRANS or COMMIT. To roll back
the transaction, you perform a ROLLBACK TRANSACTION statement or one of the
shorthand versions, ROLLBACK TRANS or ROLLBACK.

Note By default, transactions are rolled back. You should always explicitly commit or
roll back a transaction to indicate what you want to do.
Let's take a look at an example. The following transaction consists of two INSERT
statements: the first adds a row to the Customers table, and the second adds a row to the
Orders table. At the end, the transaction is committed using a COMMIT statement:
BEGIN TRANSACTION;
INSERT INTO Customers (
CustomerID, CompanyName
) VALUES (
'SOCOM', 'Steve Orange Company'
);
INSERT INTO Orders (
CustomerID
) VALUES (
'SOCOM'
);
COMMIT;

Figure 3.25
shows this transaction, along with two SELECT statements that show the two
new rows.

Figure 3.25: Using a transaction
The next transaction consists of similar INSERT statements, except this time the
transaction is rolled back using a ROLLBACK statement.
BEGIN TRANSACTION;
INSERT INTO Customers (
CustomerID, CompanyName
) VALUES (
'SYCOM', 'Steve Yellow Company'
);
INSERT INTO Orders (
CustomerID
) VALUES (
'SYCOM'
);
ROLLBACK;
Because the transaction is rolled back, the two rows added by the INSERT statements are
undone.
You should check for errors in a transaction before deciding to perform a COMMIT or
ROLLBACK because errors do not always stop the next line from processing. To do this
in SQL Server, you use the @@ERROR function. This function returns zero whenever a
statement is executed and doesn't cause an error. If @@ERROR returns a nonzero value,
you know an error occurred. If @@ERROR returns 0, you perform a COMMIT,
otherwise you perform a ROLLBACK.
You can also assign a name to your transaction in the BEGIN TRANSACTION
statement. This is useful as it shows which transaction you are working on.