由于他们不能针对操作更改ADO.NET错误集合的问题，提供完整的解决方案，他们将不会ADO.NET错误给开发者带来任何东西。开发人员不得不在Entity Framework之上建立自己的ORM，如果他们确实要ADO.NET错误在上下文外部操作数据的话。

本文的余下部分是相当冗长的示例，它关于如何使用新API来执行更改跟踪。这包括创建接口（例如IEntityWithChanges）、像GetEntityState那样使用手写的方法进行映射、或者在一个方法中两者都使用，该方法接收上下文对象、实体状态名称、ADO.NET错误实体图的方法与实体状态映射等。记住，这只适用于保存更改，你仍要先以某种方式跟踪该更改。

Ayende Rahien解释了它是如何完成的：

下面是用NHibernate的处理方法：
session.Merge( entityFromPresentationLayer );

Frans' LLBLGen支持类似的功能。换句话说，这是数据访问框架做的事，而非开发人员。
谈到Frans Bouma，下面是他总结的一些情况，

所有那些使用数据集的开发者，如何确信EF是正确方式呢？数据集在什么时候解决过这个问题的呢，从一开始吗？ADO.NET错误更别提是不是那些大量竞争性的O/R映射器框架？我想核心的问题是设计框架的错误，从框架开发人员的角度来看：ADO.NET错误在你编写框架时。

有两种“正确点”——来自框架开发者的观点（Point Of View，POV）和来自框架用户的观点。核心的错误是假设这两种“正确点”实际上是一样的，更糟糕的是：假设框架开发者关于“正确点”的观念，即是框架用户所想。#t#

在ADO.NET错误中,虽然对于服务器端的游标不提供任何支持,但这不意味着你就不能使用游标.实际上,你所需要做的步骤是在.NET中输入ADO库.你只需在references node上单击右键,就可以在你自己的程序里运行本地ADO 对象.

但是我个人认为,在你想转向.NET时,请慎重考虑. 首先,请务必完全输入ADO, ADO.NET错误这不会花费太多时间和精力,这是向.NET迈出的第一步,.但是,这仅仅是万里长征的第一步而且也是通向.NET必须的一步. .NET的真正附加值是基于一个均匀的,持续稳定的接口以及本地classes的广为应用之上的.关于COM libraries是可以被支持的,合理的,但不被鼓励的,因为它仅仅是个短期解决方案,或者是一个过渡步骤。