Calling HasChanges() after AcceptChanges() should always return false, right?

[Matt Young]

I've got this snippit of code,

DataSet clientData;
clientData.AcceptChanges();
Debug.Assert( ! clientData.HasChanges());

And the Assert fails sometimes. I can't think of why the dataset would still
have changes after AcceptChanges is called.

Has anyone else encountered the behavior or have any suggestions? Thanks!

 

[Peter Foot [MVP]]

Is that a "real" snippet of code? Only if you called that you'd get a null
reference exception since you haven't initialised clientData- somwhere you
need to create a new DataSet and assign it to clientData either
DataSet clientData = new DataSet();
or some method which returns a new DataSet into clientData.

Peter

 

[Matt Young]

Thanks Peter. Sorry, of course that wasn't a 'real' snippet of code. It was
an overly simplified version of what I'm using. Here's a more detailed
overview of what I'm doing,

// Create the DataSet
DataSet clientData = new DataSet();

// Fill it with a bunch of DataTables and DataRows
// Allow the user to edit the data through a UI
// Get the changes
// Save them to a database
// Just image the code is here, cause it is in my app.

// Call AcceptChanges (because the changes were just saved to the db and so
HasChanges() will return false)
clientData.AcceptChanges();

// Verify HasChanges() is false
Debug.Assert( ! clientData.HasChanges());

Ok now the weird behavior I'm experiencing is, sometimes HasChanges()
returns True after I just called AcceptChanges(). Should this ever happen?
The MSDN API docs give me the impression that HasChanges() should always
return False if called immediately after AcceptChanges(), am I wrong (or
smoking crack)?

My app calls HasChanges() all over the place to determine if the dataset is
in a state OK to discard (i.e. it contains NO changes that need to be saved
to the database). One of our testers started hitting weird bugs which I
tracked down to AcceptChanges() not doing its job (or what I understand to
be its job). That's what lead me to put the Assert right after the
AcceptChanges() call.

clientData.AcceptChanges();
Debug.Assert( ! clientData.HasChanges());

So now our testers hit that failed assert occasionally. And I'm back to
wondering should HasChanges() in this context return True or am I smoking
too much crack? Help!

Matt

 

[Matt Young]

Subject: Re: Detecting updates, and persisting to SQL Server
Date: 12/15/2004 6:45 PM PST
By: Kevin Yu [MSFT]
In: microsoft.public.dotnet.framework.adonet
....

 

[Ilya Tumanov [MS]]

This assert should never fire unless you're modifying DataSet from another
thread and/or via data binding.
Also, do not overuse HasChanges(). It's CPU intense as it actually
enumerates all the rows to see if any of them is changed.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------