Microsoft ADO.NET represents a major step forward for Microsoft data access technologies. It gives developers an unprecedented level of control over how their code interacts with their data—a welcome advance for developers who have been frustrated by the lack of control offered by previous "black box" technologies such as the ADO cursor engine, the Microsoft Visual Studio 6 Data Environment, and the MSDataShape OLE DB Provider.

ADO.NET is not only the most powerful and robust data access technology that Microsoft has produced to date, but it also requires arguably the steepest learning curve. I've watched a number of experienced Visual Studio 6 developers struggle with the ADO.NET object model in usability studies, trying to figure out where to get started. Developers who grasp the basic object model still wind up asking questions about some of the nuances in ADO.NET's feature set, such as "How do I control the table names that the DataAdapter uses to map the results of my batch query to my DataSet?" or "Why do I get duplicate rows in a DataSet that I build by hand if I fill it twice, when the same code doesn't create duplicate rows if I use a DataSet generated by Visual Studio .NET?"