Andy:
I agree it would be nice, but I'm guessing that not having it doesn't stop
you from getting what you need and they are busy building other
functionality into ADO.NET. From what I've seen in 2.0, things have changed
so drastically, they've been busy with other things. In all honesty though,
we seldom can use a DataTable in a database outside of the context of a
Database so as far as the metaphor goes, you'd normally have a dataset if
you were keeping with it. I will certainly admit that many times when you
only need a datatable, having to create a dataset is a pain.
As far as HasChangesChange, I don't think that would be necessary per se b/c
you can capture the RowChanged event in a DataTable.
RowChanged could change the value of a module level variable so you could
check that, and you could also use this variable to raise your own official
HasChangesChanged event if you wanted, although I think it would be
overkill. If you want to do it, create a class that has a Changes Property
and a ChangesChanged Event. Declare in instance of this class at the module
level and in the RowChanged event handler, use myChangeObject.Change = true.
In the Set Accessor, the value evaluates to true, raise your ChangesChanged
Event. I think you don't need this step b/c RowChanged will give you this,
but it's easy enough to implement if you want. You can also use this to
test if your datatable has changed. You could just poll this variable for
HasChanges so that it ONLY refers to a specific table not the whole dataset
and as such, you effectively have DataTable.HasChanges.
HTH,
Bill