The ADO.NET architecture can be divided into two main groups: connected and disconnected components.

The connected components are the ones that actually access a database, the disconnected ones accordingly is the offline (local) copy of a subset of the database, which is relevant to the application. The following separation between connected and disconnected is purely my own and does not necessarily reflect the opinion of Microsoft, but I it the most fitting scenario.

break down.

High-Level connected components are

Connection: provides the connection to the database.
Transaction: controls transaction in the database.
Command: executes (usually) SQL commands on a database. A Command can also have a number of Parameter.
DataReader: a forward- and read-only access component for data
DataAdapter: the interface component between connected and disconnected classes. A DataAdapater most importantly can fill data into a DataTable. I decided to put it into the connected components, although strictly seen it does not access the database, as it uses a DataReader for its purposes.        

High-Level disconnected components are

DataSet: a container for a number of DataTable instances and its relations (DataRelation) to each other.
DataTable: an offline cache of a (sub)set of data. A DataTable has DataRow, DataColumn and Constraint collections.

The following diagram tries to show the dependencies between the components:

netguide-adooverview

The connected components are actually defined as Interfaces and the.NET framework already includes implementations for MS SQL Server and MS OLEDB (mostly to access databases via older ODBC drivers).

As a general rule: for accessing a certain database engine you need fitting implementations of the mentioned connected components. Thus these are the interfaces an ADO.NET Provider must implement for its database. The disconnected components will work with any full implementation of these interfaces, in fact they are sealed classes and can't be overridden or extended (which in my opinion is a shame).

Some more information for Delphi developers

Back to the question "What now?". Due to the different concepts of the data access models, the new application uses a different approach than the old TDataset based one. I also took the opportunity to clean up the design of the database, which makes the whole project a complete rewrite. Not what I thought in the beginning but probably nothing bad either.

This "everything new" was mainly made necessary because the application was solely based on TTable components. An application that is based on SQL (TQuery) can be converted and kept very similar to the original, if, and only if, it was not using live results.

Home | Site Contents | Documentation | NexusDB Manual V4 | .NET Guide | Developing a database application with .NET