We're through with wizards!

Many have wondered whether the (actually, really good) wizard support in VB .NET is there because there are simply so many parameters and options to keep track of.

There is a 'pro' and a 'con' to all this complexity. The 'con' is that ADO .NET can be tough to learn and tough to debug. The 'pro' is that ADO .NET is extremely flexible and dynamic and you can do anything. Actually, another 'pro' for the programming professional is that there really is a great need for programmers who know what they're doing to navigate this complexity. In this installment of the About Visual Basic ADO .NET tutorial, we confront the complexity head on and examine how to program against the ADO .NET objects directly!

-----------------------------------------

About.com also has a database focused site at databases.about.com.

This series will focus on the VB .NET language aspects of ADO .NET. Go to About Databases for more information 'About' building and using databases.

-----------------------------------------

In Part 1 of this series, a simplified diagram of ADO .NET objects was introduced:

To code ADO objects ourselves, we need a more complete view:

You should notice a few changes.

For one, we now have an Oracle managed provider! An Oracle managed provider was added in the VS 2003 (version 1.1) upgrade in April 2003. This is really a significant step for Microsoft because it shows they are committed to making ADO .NET work with the world's data, not just the data in their own proprietary systems. But to keep things simple, we'll continue using the ODBC provider as we did in previous installments of this tutorial. This isn't a great sacrifice because once you create a Connection object and open a datasource successfully, ADO .NET works pretty much the same way with all datasources. It's one of the great strengths!

Another difference is that the DataReader is not shown. DataReader is the 'fast and forward only' provider ... used for reading the database but not updating. We need more power this time.

And still another difference is that our chart this time is intended to illustrate how the objects function rather than how they're organized. Starting from the data on the left side, the Command and Connection objects are used by the DataAdapter to build a DataSet that is in a common format for all ADO .NET providers.

The main benefit of this, and one of the greatest innovations of ADO .NET, is that once you build a DataSet in your project, you can process it in about the same way no matter what the original source of the data was. It doesn't really matter to your program where the data came from. The DataAdapter objects provide the unique capability that different sources of data require but they all create the same DataSet object.

Next page > ADO .NET: Built for Networks > Page 1, 2, 3, 4, 5, 6