Attention: We are retiring the ASP.NET Community Blogs. Learn more >

ADO.NET: Is my data really dirty?

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

  

 

 

5 Comments

  • But the question then is; If another user changes data, and the first person hits save, should the first person have an option to revert to the data they have typed in.



    Remember, it is possible the dialog has been open for a day or two.



    It now becomes an issue of having a &quot;semi-dirty&quot; state, where the user has changed the data and reverted it back to the original by manually re-entry. You would then have to check the semi-dirty data against the data stored in the database for concurrency issues.



    In my opinion, it's much easier to just have a dirty and &quot;clean&quot; state since you will have to do a round trip to the database in any case once the user has indicated they want to change the data (by changing fields).



    Sorry I can't make it clearer, but I'm in a bit of a rush, =/

  • I guess another way of thinking about this is:



    Did the user make a change or not make a change? Per the databound ado.net model, yes in the above exampled (DataRowState.Modified).



    Per the user's expectation\perception, no.



    I've have worked with many an app where a change from orgianl to current then back to the original value is counted as a save and a trip to the database. I disagree with this.




  • &lt;quote&gt;

    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?

    &lt;/quote&gt;



    Yes. MS Word works like that.

  • интеретсно написано

  • 50 % discounts on all airtickets flights and hotels as well as all football matches
    email us at makitelove@yahoo.com

    no advance payment needed

Comments have been disabled for this content.