由于他們不能針對操作更改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是可以被支持的,合理的,但不被鼓勵的,因為它僅僅是個短期解決方案,或者是一個過渡步驟。