Page 307 - DCAP408_WEB_PROGRAMMING

Unit 14: Database Connectivity

rows from the data source and then drop the connection, or it can read all the needed information Notes
from a client disk file, including an XML file with a fixed schema.
The disconnected facilities of ADO have been bolted on the Recordset object interface, paying
careful attention to make connected and disconnected functionalities available through equivalent
APIs. As a result, the Recordset became hard to wield, rather overwhelming and with significant
housekeeping.
Anyway, in ADO you can get data in three ways:
1. Through full-time connection using server cursors.

2. By the means of a fast, read-only, forward-only mechanism specifically thought to read
through and process a set of records.
3. Getting a static snapshot of data, processing them disconnected from the data source and
submitting changes at a later time.
Whatever way you work, you always use the Recordset object and choose the operating mode
by selecting the proper cursor type and location. (See the ADO documentation for more details.)
An obvious drawback is that no matter how optimized and well-designed the Recordset object
is, you load in memory more stuff than you actually need. In addition, it adds an extra layer of
code to process input parameters and possibly fixes their values.

Notes Given the overall programming interface of ADO, this is an absolute necessity as
well as a performance hit.

ADO.NET simplifies the data reading infrastructure by applying the old “divide et impera”
motto. It introduces two new objects that don’t have particularly familiar names but expose
certainly well-known functionalities. They are the Data Reader and the DataSet.
The Data Reader object is the ADO.NET counterpart of the read-only, forward-only default ADO
cursor. The DataSet is a container that can be programmatically filled with static snapshot of
data. In this sense, it can be seen as a repository of disconnected recordsets. There’s no Recordset
component in the ADO.NET object model, but the DataTable object is the .NET double of a
disconnected recordset.
In ADO.NET there’s no explicit support for server cursors even though, in a future version, you
can expect to see ADO.NET to support server cursors when the data provider is SQL Server 7.0 or
later.
If you need server cursors tody, just import the ADO type library in your .NET application and
code through it. To learn more on this good, bad and ugly, see the previous column, ADO Rocks
and Rolls in .NET Applications.

ADO.NET is designed around XML to work seamlessly in highly interoperable and disconnected
scenarios. From this point of view, it is certainly more appropriate than ADO for the breed of
applications that the majority of people are writing and planning today. It simplifies the coding
and optimizes the working of data access components that have Web-based clients.
It behaves well also when you have a Web-enabled database server such as SQL Server 2000 with
the XMLhttp support.
Despite the actual syntax differences, the programming philosophy behind ADO and ADO.NET
is aligned as much as possible to reduce the learning curve for data access developers and the
quantity of new concepts they have to familiarize with.

LOVELY PROFESSIONAL UNIVERSITY 301