THE STRUCTURE OF A DATASET 969

As you can see, there’s no compelling reason to bind your controls to the fields of a DataSet. You can access any field of any row of any table of the DataSet from within your code and display its value on a control. You can even apply any formatting necessary to the field’s value before displaying it. If the user changes the value of the field, you can validate it before it’s even stored to the DataSet.

The examples so far have dealt mostly with the presentation of data. Now we’re going to look into the process of updating the DataSet, as well how to update the underlying tables in the database.

Updating DataSets

In the previous chapter, you learned how to update the tables in the database through the DataAdapter object. This technique, however, isn’t very robust, and here’s why. You may start with a DataSet of 30 changed rows. Some of these rows may contain errors, and the DataSet won’t update the rows in

error. You’ll have to select all rows in error, figure out what went wrong, and try again. Fixing the errors means that you must present all the information to the user and give them a chance to edit the rows again, then try to update the database again.

Some rows may contain errors that can’t be fixed by the user. Let’s say the user has edited a row, but in the meantime another user has removed this row from the underlying table in the database. Obviously, the DataAdapter won’t be able to update this row, because it no longer exists in the database. This is a typical error that may stop the DataAdapter from updating the remaining rows.

Another messy situation arises when a table contains an identity column, one that is assigned a value automatically by the database. The ProductID column in the Product database is such a column. Let’s say you’ve created a DataSet that contains the products of the Northwind corporation. It is possible to add new rows to the Products table, and the DataSet will automatically assign a new value to the ProductID field. This field is certainly unique in your DataSet, but another user may have already added a row with the same ID to the database. Handling this type of error isn’t trivial.

There’s a simple work-around for new databases, but this can’t be applied to existing databases. You can use GUIDs (globally unique identifiers) instead of Identity columns. A GUID is a systemgenerated number that’s globally unique. It’s generated in such a manner that’s extremely unlikely that there will ever be a conflict with two GUIDs. In the unlikely case that there’s a conflict (the system generates a GUID that already exists in the table), the operation will fail. But this is a remote possibility, and we can live with it. The problem with Identity columns is that they’re used extensively in existing databases, and we can’t redesign our databases.

Another problem arises with constraints other than the referential constraints. The UnitPrice column in the Products table has a constraint that prevents it from accepting a negative value (a very reasonable constraint). Should you attempt to store a negative value in this column, the database will reject the changes. This constraint, however, isn’t stored in the DataSet. In other words, you can edit a row of the Products table in your DataSet, set UnitPrice to a negative value, and the changes will be stored in the Products table of the DataSet. When you attempt to update the database, however, the row will be rejected. To handle this type of error, you must supply all the necessary validation code. But then again, how can we be sure that we have caught every possible error?