976 Chapter 22 PROGRAMMING THE ADO.NET OBJECTS

If an error occurs, the exception handler will display the description of the error in a message box, then it will clear the edits and move to the product selected in the ListBox control. The user can select the previous row and edit it again, knowing what type of error prevented the update of the DataSet.

If you click the Delete button, the current row will be removed from the DataSet (it will also be removed from the ListBox control, just as new rows are added automatically to this control). But products are referenced in the Order Details table, so how can we delete them? Remember, the DataSet resides in the local computer and is disconnected from the database. Since the DataSet contains a single table, there are no relations to be enforced and the DataSet happily removes the row when you request it. What will happen when you attempt to update the database, however, is a different story. SQL Server will emphatically refuse to remove a row that’s being referenced by another table, and the update operation will fail. Delete a row, then click the Update button. You’ll get an error message to the effect that the row can’t be removed because this would violate the PK_Order_ Details_Products constraint.

Handling Identity Fields

I should point out the following behavior of the application. If you add a row, its ProductID field will be assigned a value automatically. The ProductID column is an Identity column, and you can’t set it; it must be assigned a value by the DBMS. The DataSet knows that the ProductID column is an Identity column and, every time you add a row, it assigns the next available value to it. If the last row’s ProductID field is 90, it will assign the value 91 to the first row you add, the value 92 to the second row, and so on. But what will happen if another user has already added a few rows to the table? Run the application again, add a couple of rows, and then switch to the Enterprise Manager. Do not update the database yet.

In the Enterprise Manager, add a couple of rows to the Products table. Then switch to the application and click the Update button. The new rows will be added to the underlying table. Write down the IDs of the new rows. Then load the DataSet again by clicking the Load button, locate the newly added rows, and examine their IDs. This time they’re different! They have the values assigned to them by the database.

This is a reasonable behavior too, as we don’t really care about the IDs of the rows. Or do we? In an application like EditProducts, no one would really care to see the actual ID of a product. There are situations, however, where you may want to use the ID of a row as a foreign key in another table. Let’s say you want to issue an invoice. First, you must add a row to the Orders table. The new order will get an ID from the database. This ID, however, must appear in all the rows of the Order Details table that refer to the specific invoice. And obviously, we must make sure that the proper ID is inserted in the Order Details table (it must be the final ID of the order assigned by the database, not a temporary ID generated by the DataSet).

Retrieving Proper IDs

There are situations where we do need to know the proper ID assigned to an identity field by the database. The best way to handle these situations is to create a stored procedure that accepts the fields of a new row, writes it to the database, and returns the ID assigned by the database. Although

THE DATAFORM WIZARD 977

this can be done through the DataSet object, why bother with a mechanism that’s optimized for disconnected scenarios? We want to connect to the database, commit the new row, and get back its ID as soon as possible. You see, the DataSet was designed for a disconnected world, but not all dataaccess requirements fall into this category. It’s highly unlikely that ADO.NET will remain for long a disconnected data-access mechanism—Microsoft will have to add features to make ADO.NET work in connected scenarios like the one described here.

Instead of using the DataSet to update the database, we can use the Command object. I discussed the Command object in Chapter 21, but I will repeat the process here by demonstrating how to add a new row to the Orders table. First, you must create a stored procedure that inserts a new row to the table. The only required field for the Orders table is the ID of the customer that placed the order. The order’s date (OrderDate field) can be assigned the current date and time by the database. The remaining fields (the ID of the employee who made the sale, the shipping address, and so on) are optional. To keep the complexity of the sample code to the bare minimum, I will ignore these fields.

The stored procedure in Listing 22.6 accepts as argument the ID of a customer and creates a new row in the Orders table. After the execution of the INSERT statement, the stored procedure retrieves the value of the identity field of the new row (it’s given by the expression @@IDENTITY) and returns it to the calling application.

Listing 22.6: The NewOrder Stored Procedure

CREATE PROCEDURE NewOrder @custID nchar(5)

AS

INSERT INTO Orders (CustomerID, OrderDate) VALUES(@custID, GetDate()) RETURN (@@IDENTITY)

GO

The value returned by the stored procedure is known as its return value, and you’ll see shortly how you can retrieve it from within your application.

Once the stored procedure is in place, you can create a new Command object to call the stored procedure. First we establish a Connection object to the database, then we open the connection and assign the Connection object to the Connection property of the Command object.

The Command object’s CommandText property is set to the name of the stored procedure, and its CommandType property is set to the constant CommandType.StoredProcedure. At this point, we can execute the stored procedure, but we must first add some parameters to it. We create a new Parameter object for each parameter expected by the stored procedure, set its name, type, and value, and then add it to the Command object’s Parameters collection. Finally, we call the Command object’s ExecuteScalar method, which returns the stored procedure’s return value. Listing 22.7 shows how to add a new row to the Orders table and then retrieve the new row’s OrderID field. If the new row can’t be added to the table, the stored procedure will raise an error (it will also return the value zero). The ID of the new row is then stored in the orderID variable for further processing.