| One of the design goals of ADO .NET was to phase out reliance on OLEDB, the database access technology based on COM+. Microsoft also realized that there are a large number of OLEDB providers that are well established. To accomplish this goal and retain backward compatibility with OLEDB providers, Microsoft created two branches to the data access classes. The OleDbClient set of classes can use any of the existing OLEDB providers except the ODBC OLEDB provider [1] . The SqlClient set of classes does not use OLEDB. It is a native ADO .NET data access technology. It is Microsoft's goal to see third parties build other database-specific providers. There is already an Oracle client set of classes in beta. There are advantages and disadvantages to both approaches. In this section we will go over the benefits and drawbacks of each set of classes. [1] There is a special ODBC .NET driver available from http://msdn.microsoft.com/downloads. The two sets of classes are roughly parallel. That means that while the class libraries mostly have counterparts in each client, it is not 100 percent. For example, the SqlClient's SQLPermissions class has a counterpart in OLEDB, but the properties and methods do not fully line up. This makes cross-database platform development difficult, and requires that some intermediate component layer be built that can adapt itself to the underlying database. One answer would be to exclusively use the OleDbClient classes, but there is a performance price as they are not as efficient as the native SqlClient classes with SQL Server databases. Which set of classes you use depends on your design goals. If you must design for cross-database compatibility, my advice would be to use the OleDbClient classes. Even then, you will have to write some database-specific code. While cross-database compatibility was a consideration some years ago, I think that it is less of an issue now. I remember having to create cross-database systems, only to find that all implementations were on SQL Server. All that extra programming was never used. The good news is that the two sets of classes merge with the DataSet. The DataSet was designed to be database-neutral. Both sets of client classes send their data to the DataSet for storage and local manipulation so your presentation-layer code can be one single code base. This is an improvement over the past where even the RecordSet would be slightly different for different database systems. Any future ADO .NET client classes (Oracle for example) also must provide data to the DataSet in order to conform to the ADO .NET standard. Next we will summarize most of the ADO .NET classes, starting with the database access classes and the two clients (SQL and OleDB). We will discuss the classes together. I will note where they are different; otherwise you can assume they are the same. Then we will summarize the DataSet and the classes that it uses. We will discuss these classes and more in further detail in the separate chapters on each.  | 
