AcceptChanges called by UpdateDataSet?

Topics: Data Access Application Block
May 23, 2007 at 12:20 PM

The UpdateDataSet method of the DAAB OracleDatabase class appears to call AcceptChanges() 'for' me.
1. Is this truly the case?
2. Can this behavior be turned off?

May 23, 2007 at 12:34 PM
Hello again,

After posting the above message, I found the relevant information in a different discussion.

So, my 2 cents worth....

It seems to me that this automatic acceptance of changes was not happening in at least one earlier version of the data access block (should memory serve). I would like to see it reintroduced. For myself, I was counting on that earlier behavior to support audit trails, but now, what was previously a simple exercise becomes a tedious procedure cloning and matching datatables to locate the columns in the rows which were changed (and updated).

If anybody else here can contribute a way to update a dataset without calling AcceptChanges using Orcale and the DAAB, please post it.


May 23, 2007 at 1:34 PM
The DAAB doesn't call AcceptChanges(), at least not in Enterprise Library 2.0 or 3.0.

It only calls adapter.Update( ... ).

Adapter.Update calls AcceptChanges() as part of its process of updating the table. This is built into ADO.NET 2.0.




David Hayden
Microsoft MVP C#
May 23, 2007 at 3:38 PM
Yes. I misspoke. I saw the call to adapter.Update and called it a DAAB behavior.

Wrong place to say it, but this new 2.0 behavior should not have completely supplanted the original behavior. That was a useful thing to have.
May 23, 2007 at 3:51 PM
I don't have Enterprise Library 1.1 on my machine to verify what it was doing. It may be that the DAAB didn't change at all and what you are experiencing is a change in ADO.NET.




David Hayden
Microsoft MVP C#
May 23, 2007 at 4:07 PM
I agree. The 2.0 I referenced above was ADO.NET 2.0 and not EntLib.

I am trying to find other ways around this. But it does not look promising. Anything that goes through EntLib will probably get to adapter.Update.

I wonder if it still returns RowErrors or if they are erased when AcceptChanges are called and the update behavior is = Continue? If that is true then I have to use the RowUpdated Events and they look pretty expensive - one or more roundtrips to the server for each row updated?