locally, and you need to be aware of all the possibilities in order to be able to
make an informed decision about which mode to use.
Working with Data Sets and Data Tables
We’ve been working with databases for a while now. You first learned about the
SqlDataReader, and used it to populate your controls. Then, in the first half of
this chapter, we gained first-hand experience with the data source controls, which
can automate many features for you. Let’s learn about one more technique you
can use to get data to your visitors.
I know that all these options can be confusing at first—you need to play around
with all of them before you can become an experienced ASP.NET developer!
The DataSet object is at the center of Microsoft’s model for presenting discon-
nected data. Disconnected data (data that resides in memory and is completely
independent of the data source) gives us a raft of new opportunities of developing
desktop and web apps.
In Chapter 9, you learned about the role that data readers play in relation to
applications and database data. Whenever we need to access data from a database,
we create a connection object and a command object. These two objects are used
together to create a data reader object, which we can use within our application
by binding it to a data control for presentation purposes. Figure 12.18 illustrates
So, what’s the problem? Well, while being the fastest way to retrieve data from
a database, data readers can’t be used to carry out any significant work—you
can’t use them to sort, filter, or page through the data. As the arrows in Fig-
ure 12.18 show, data readers present a forward-only stream of data to the applic-
ation: you can’t go back to a previous record, or reuse that data reader somewhere
else. Moreover, once a data reader has been created, it remains tied to the data-
base. This means that you can’t make multiple requests to a database using the
same data reader.
Data sets, on the other hand, are much more flexible. Imagine a virtual database
that you’re free to use in code whenever and however you wish. That’s a data
set. As we’ll see in the next section, data sets have all the bells and whistles that
databases offer, including tables, columns, rows, relationships, and even queries!
A data set is a memory-resident copy of database data, so, once a data set has
been created, it can be stored in memory and its ties to the database can be
broken. Then, when you need to work with the data, you don’t need to re-query
Chapter 12: Advanced Data Access
Figure 12.20. Multiple pages making multiple requests from the
same data set
An even greater advantage is that data sets can be shared among multiple requests,
as illustrated in Figure 12.20.
What this means is that you simply need to create the data set once per request.
Once the data set has been created, it can be used by many different pages, all
of which may make multiple—and even different—requests to that data set.
However, data sets require much more memory and resources than do data
readers. A data reader simply keeps track of its position within the results of a
query, whereas a data set can contain a local copy of an entire database. The
larger the amount of data kept in the data set, the more memory the data set
When deciding whether to use data readers or data sets, you need to consider
the purpose for which you need the data. This decision is important, because it
resources consumed on the database server
resources consumed on the application server
the overall application architecture
If you’re only reading the data, using a data reader can make sense. If you also
need to update, insert, or delete data, or you need to process the data within
your code, data sets might be of more help.
This section will teach you everything you need to know to begin working with
Chapter 12: Advanced Data Access