KB Article Number(s): 822690
This one has resolved a lot of our IDE bugs.
Example: User changes the value in a databound control. Users changes the value back to it's original value. User initiates a Commit\Save.
Should the save go through?
No in my opinion. The data has not 'really' changed from the user's point of view.
If you are using the ADO.NET update model though, the DataRow gets marked as Modified.
How to 'prevent' this? You can't unless you call RejectChanges on the DataRow.
So, write yourself a DataDirty method to check each column's current value and compare it to the original value. If they are not different for all columns in the DataRow, RejectChanges.
Public Function DataReallyIsDirty(ByVal dt As DataTable) As Boolean
Dim result As Boolean = False
For Each drw As DataRow In dt.Rows
If drw.RowState = DataRowState.Modified Then
Dim curr, orig As String
For Each col As DataColumn In dt.Columns
Try
curr = drw(col, DataRowVersion.Current).ToString().Trim()
orig = drw(col, DataRowVersion.Original).ToString().Trim()
If (Not curr.Equals(orig) OrElse _
curr <> orig OrElse _
String.CompareOrdinal(curr, orig) <> 0) AndAlso _
Not (curr = "-" AndAlso orig = String.Empty) Then
result = True
End If
Catch
Throw
End Try
Next
Else
If drw.RowState = DataRowState.Added Then Return True
End If
Next
Return result
End Function ' DataReallyIsDirty
http://www.msnbc.msn.com/id/6677040/
Too funny. Hits home though, as the Mrs.and I are, well you know, shall we say "considering starting a family". Or, as a politically correct friend of ours said "You are in negotiations for reproduction"
Shawn has given me a lot of good advise on different LISTSERVS. So, I figured it was time I purchased his book and read it.
I guess you could call me the ADO.NET guru at our shop. We all try to specialize in something and this is what I chose 3 years ago. I have read a lot of books and white papers on ADO.NET.
That said, Shawn's book was a quick read for me (about a week, 1-2 hours a night). The book's content is invaluable though if you are learning ADO.NET.
Shawn writes with personality and a little humor. It makes the book fun to read and it flows well. He does not regurgitate the SDK. He introduces a topic, explains it well with a sample or two and a small amount of code (C#) and then moves on. He does not throw volumes of code samples or flow chart\grids at you. One of my pet peeves with tech books is too much code and too many fluffy pictures. There is nothing worst than reading and coming to 10-15 pages of copied\pasted code or 2-3 pages of pretty\fluffy flow charts. Boring IMHO. Stick it on a cd or web site and refer me to it.
Shawn does a nice job covering the things you will need to know and most likely use everyday. He does not waste time covering some cool and neat, that, though it's cool and neat, has little daily value to you as a developer. He covers design techniques very well to.
I did not read the chapter 6 as I am not a fan of typed datasets.
I can honestly state I learned something from every chapter. Most was review, some was "oh yeah, I forgot about that". I especially like the Best Practices section in chapter 11.
My only complaint: he is obviously an Atlanta Braves fan ;-(
I would give the book at least a 4, maybe a 4.5 on a 5 scale. Nice job Shawn and thanks for all the tips.