Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You can use the new DataSets to create relationships and constraints, notes Brust. A DataSet can also be inherited to create a "strongly typed DataSet," which exposes rows and columns as properties as an object, rather than items in a collection.
Yet if you're using a strongly typed DataSet, you need to be careful in handling nulls. Microsoft admits that the XSD schema of the DataSet will throw an exception if a null reference is found. However, you can use the nullValue annotation to replace DBNull with a specified value, String.Empty, persist the null reference, or throw an exception.
Along with DataSet, you might find yourself using some or all of the following componentry and methods:
DataAdapter, DataAdapter.Fill, and/or CommandBuilder—for interacting with the data source;
DataView—for sorting and filtering.
Essentially, DataAdapter acts as a middleware liason between the DataSet and data source. DataAdapter.Fill—fast getting slangified as 'Data.Fill,' or even just 'Fill'—comes into play for filling the DataSet with schema, or for refreshing the values in a DataSet with values from the server, for example.
"DataView gives you a traditional kind of database view," Brust observes. CommandBuilder, on the other hand, automatically generates DataAdapter's InsertCommand, UpdateCommand, and DeleteCommand properties, based on the DataAdapter's Select/Command properties.
However, Microsoft suggests that you limit CommandBuilder to design time or ad hoc use. "The processing required to generate the DataAdapter command properties hinders performance," according to another document on MS's site.
The two command objects in ADO.NET—OleDbCommand and SqlCommand—can be used to do either of the following:
Invoke the DataReader object (.ExecuteReader)
Action an SQL statement upon the data (.ExecuteNonQuery)