What Happened to Your ADO Cursors?
One big difference between classic ADO and ADO.NET is the way they handle cursors. In ADO 2.x, you have
the option to create client- or server-side cursors, which you can set by using the
CursorLocation property
of the Connection object. ADO.NET no longer explicitly assigns cursors. This is a good thing.
Under classic ADO, many times programmers accidentally specify expensive server-side cursors, when
they really mean to use the client-side cursors. These mistakes occur because the cursors, which sit in the
COM+ server, are also considered client-side cursors. Using server-side cursors is something you should
never do under the disconnected, n-tier design. You see, ADO 2.x wasn’t originally designed for disconnected
and remote data access. The
CursorLocation property is used to handle disconnected and connected access
within the same architecture. ADO.NET advances this concept by completely separating the connected and
disconnected mechanisms into managed providers and DataSets, respectively.
In classic ADO, after you specify your cursor location, you have several choices in the type of cursor to
create. You could create a static cursor, which is a disconnected, in-memory representation of your data-
base. In addition, you could extend this static cursor into a forward-only, read-only cursor for quick
database retrieval.
Under the ADO.NET architecture, there are no updateable server-side cursors. This prevents you from
maintaining state for too long on your database server. Even though the DataReader does maintain state on
the server, it retrieves the data rapidly as a stream. The ADO.NET DataReader works much like an ADO read-
only, server-side cursor. You can think of an ADO.NET DataSet as analogous to an ADO client-side, static
cursor. As you can see, you don’t lose any of the ADO disconnected cursor functionality with ADO.NET;
it’s just architected differently.
Connecting to a Database
The first step to using ADO.NET is to connect to a data source, such as a database. Using the Con-
nection object, you tell ADO.NET which database you want to contact, supply your username and
password (so that the DBMS can grant you access to the database and set the appropriate privileges),
and, possibly, set more options. The Connection object is your gateway to the database, and all the
operations you perform against the database must go through this gateway. The Connection object
encapsulates all the functionality of a data link and has the same properties. Unlike data links, how-
ever, Connection objects can be accessed from within your VB .NET code. They expose a number of
properties and methods that enable you to manipulate your connection from within your code.
Note You don’t have to type this code by hand. The code for all the examples in this chapter is located on the companion
CD that comes with this book. You can find many of this chapter’s code examples in the solution file
Working with
ADO.NET.sln
. Code related to the ADO.NET Connection object is listed behind the Connect To Northwind button on
the startup form.
Let’s experiment with creating a connection to the Northwind database. Create a new Win-
dows Application solution and place a command button on the Form; name it Connect to
Northwind. Add the
Imports statement for the System.Data.SqlClient name at the top of
the form module. Now you can declare a Connection object with the following statement:
Dim connNorthwind As New SqlClient.SqlConnection()
233
THE CONNECTION OBJECT
2878c06.qxd 01/31/02 2:14 PM Page 233