Questions That Should Be Asked More Frequently

Features of the DataSet Object

At its core, a DataSet object is a set of data. When developers picture the results returned by a query, they generally picture data in a grid, much like a Microsoft Excel spreadsheet. You can use a DataSet to store the results of a query, but a DataSet more closely resembles an Excel workbook because it can hold the results of multiple queries.

But the ADO.NET object model already lets you examine the results of a query through the DataReader object. Why would you need another object?

In Chapter 4, you learned about the DataReader, which is a fast and efficient structure that lets you retrieve the results of a query. The DataReader is built for speed because it supports very limited functionality. The data in the DataReader is read-only, and once you've moved on to read the next row, there's no going back to reexamine previous rows.

The DataSet object provides much more powerful functionality. Let's take a look at some of the features available through the DataSet object.

Working with Disconnected Data

The data in your DataSet is disconnected from your database. Once you fetch the results of a query into a DataSet using a DataAdapter object, there is no longer a connection between your DataSet and your database. Changes you make to the contents of the DataSet will not affect your database. If other users modify data in your database that corresponds to the data in your DataSet, you will not see those changes in your DataSet.

Working with disconnected data structures definitely has its benefits. The first major benefit of working with disconnected data is that it does not require a live connection to your database. Once you've fetched the results of your query into a DataSet object, you can close the connection to your database and continue to work with the data in your DataSet.

Disconnected data structures such as DataSets are also helpful when you build multi-tiered applications. If your application uses business objects running on a middle-tier server to access your database, your business object needs to pass disconnected data structures to your client application. The DataSet object is designed for use in such situations. You can pass the contents of a DataSet from one component to another. The component that receives the data can work with the information as a DataSet (if the component is built using the Microsoft .NET Framework) or as an XML document.

Scrolling, Sorting, Searching, and Filtering

The DataSet object lets you examine the contents of any row in your DataSet at any time. You can loop back and forth through the results of your query as often as you like. This makes the DataSet object ideal for scenarios in which your code needs to loop through data, such as in reporting routines. You can also easily build an application that allows a user to scroll back and forth through the results of a query.

DataSet objects also let you change the way you view the results of queries. You can sort the data in a DataSet based on a column or a series of columns. You can search for a row of data based on simple search criteria. You can also apply a filter to the data in your DataSet so that only rows that satisfy the desired criteria are visible. We'll examine these features in more depth in Chapter 8.

Working with Hierarchical Data

DataSet objects are designed to work with hierarchical data. In Chapter 2, we used the Data Form Wizard to build a simple Microsoft Windows application that let us retrieve information from two tables—customers and orders. When you ran the application, the form that the wizard built let you scroll through the customer data. As you moved from one customer to the next, the form displayed only the orders for the current customer.

The DataSet object lets you define relationships between the tables of data stored in the DataSet. The Data Form Wizard used the input you provided to build such a relationship. The wizard then bound a DataGrid to the relationship to show only the orders for the current customer. (We'll take a closer look at the DataRelation object in the next chapter.)

Caching Changes

Working with read-only data is easy. One of the biggest challenges in building a database application is to transform the user's input into changes to the contents of your database. Building such logic into a multi-tiered application can present an even greater challenge if your application needs to cache changes and submit them to your database all at once.

The DataSet object lets you cache changes to a row of data so that you can submit the changes to your database using a DataAdapter. You can also examine modified rows in your DataSet to determine how the row has changed (inserted, modified, or deleted) as well as to compare both the original and current values for each row.

In this chapter, you'll learn about modifying the contents of a DataSet. I'll discuss submitting pending changes to your database using the DataAdapter object in Chapter 10 and Chapter 11.

XML Integration

The ADO.NET DataSet was built from the ground up to work with XML. You can save and load the contents of a DataSet to and from files as XML documents. The DataSet also lets you separate the schema information (table, column, and constraint information) into an XML schema file.

In ADO.NET, DataSet objects and XML documents are almost interchangeable. It's easy to move from one data structure to the other. This duality allows developers to use the interfaces they're most comfortable with. XML programmers can work with DataSet objects as XML documents, and database programmers can work with XML documents as DataSet objects.

We'll take a closer look at the DataSet object's XML features in Chapter 12.

Uniform Functionality

Developers who have worked with ADO might be aware that the Recordset object has features similar to those of the DataSet. The ADO Recordset object supports features such as filtering, searching, sorting, and caching updates. However, the manner in which you open a Recordset plays a large part in determining what functionality is available in the Recordset.

For example, if you use just the default settings for the ADO Recordset and Connection objects, you cannot get an accurate count of the number of rows in the Recordset. The Recordset object has a Supports method that developers often use to determine the functionality available: Can I modify the contents of the Recordset? If I update a row, will the Recordset send the change to the database immediately or will it be cached? Can I bind my Recordset to a grid? Can I move to the previous row?

The reason that not all Recordset objects support the same functionality is that the Recordset object tries to be everything to everyone. Whether you're working with a firehose cursor, a server-side cursor, or disconnected data in ADO, you're using a Recordset object.

The ADO.NET DataSet object does not require such integration because it's designed strictly for disconnected data. As a result, ADO.NET developers will never send mail to an e-mail alias asking such questions as "Why is the RecordCount for my Recordset -1?" or "What does 'The rowset is not bookmarkable' mean?"