NexusDB

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

High-Level disconnected components are

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

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.