The following tip was excerpted from Chapter 1, 'Migrating from ADO to ADO.NET,' of the book Expert One-on-one Visual Basic 2005 Database Programming by Roger Jennings, courtesy of Wiley Publishers. Click here for the complete collection of book excerpts.
Microsoft designed the basic ADO.NET feature set to resemble that of ADO. The code to create a
database connection with ADO.NET's SqlClient, OleDb, or Odbc managed providers is quite similar to
that for ADODB.Connection objects. The same is true for ADO.NET's connection-specific commands
and parameters. The primary differences between ADO and ADO.NET involve processing resultsets.
DataReaders correspond to ADO's default forward-only, read-only Recordsets. The SqlClient data
provider provides a substantial performance boost by eliminating the COM-based OLE DB layer and
communicating with SQL Server 7.0 and later using SQL Server's native TDS protocol.
ADO.NET data binding to typed DataSet objects and data-related event handling differ radically
from ADO. Many experienced VB6 database developers discovered that migrating from ADODB
Recordsets to ADO.NET 1.x DataAdapters, typed DataSets, and databound controls wasn't a walk in the
park. Creating an ordinary data entry form with ADO.NET 1.x's DataGrid or other controls bound to a
DataSet's DataTable and adding record navigation buttons involved writing much more code than that required for a corresponding VB6 project. To ease the pain of the transition from VS 6 to VS 2005,
ADO.NET 2.0 provides drag-and-drop methods for autogenerating the components and controls to create a basic, single-table form with the new DataGridView and DataNavigator controls, plus DataComponent and DataContainer components. Changing the DataGridView to a details view with individual databound controls takes only a minute or two.
The new drag-and-drop methods and component configuration wizards are useful for product demos by
Microsoft's .NET evangelists, which elicit "oohs" and "aahs" from conference and user-group attendees.
Autogenerated data entry forms can help programmers gain a basic understanding of ADO.NET data
binding and flatten the ADO.NET learning curve. But you'll probably find that autogenerated forms
aren't useful in real-world production applications. Amajor shortcoming is the default to parameterized
SQL statements for data retrieval and update operations; most DBAs require stored procedures for all
operations on base tables. Fortunately, you can intervene in the autogeneration process to specify and
create the required stored procedures. Another issue is the BindingNavigator's lack of shortcut keys,
which are a necessity for heads-down data entry. You'll discover other limitations of autogenerated forms
and their workarounds as you progress through the book.
The preceding comments on databound control autogeneration doesn't apply to generating typed
DataSets. Writing VB 2005 code for typed DataSets isn't a practical alternative. You can, however,
create lightweight, untyped DataSets with only a few lines of code. Later chapters provide code examples
to create untyped DataSets at runtime.
The following chapters of Parts I and II show you how to create production-quality Windows data entry
forms by combining some of the techniques you learned in this chapter with DataSets, TableAdapters,
and VB 2005 code to manage data retrieval, DataTable navigation, and multiple base table updates.
The above tip was excerpted from Chapter 1, 'Migrating from ADO to ADO.NET,' of the book Expert One-on-one Visual Basic 2005 Database Programming by Roger Jennings, courtesy of Wiley Publishers. Click here for the complete collection of book excerpts.
