ASP.net 2.0 Advanced Data processing Conflict detection

Asp.net| Advanced | data

　　 we mentioned earlier, data-bound controls store the values passed to the data source in separate keys, values (new values), and oldvalues dictionaries. By default, SqlDataSource and ObjectDataSource ignore the OldValues field and use only keys and values. This behavior is detected by the ConflictDetection property of the data source, and the value of this property is set to OverwriteChanges by default. OverwriteChanges mode means "to update or delete records, just match primary key values". This operation means that the record is updated or deleted regardless of whether the underlying value of the record has changed. In general, the ideal state is to have the update or delete operation succeed only if the value of the data row matches exactly the value originally selected. In this ideal scenario, your update will fail if another user updates the line between the time you select a row and update the row. The data source supports this operation by setting the ConflictDetection property to CompareAllValues. In this mode, the data source applies the oldvalues to the command or method, which uses these values to ensure that the update or delete operation must match all the records ' values before updating or deleting the record. You must also set the OldValuesParameterFormatString property to a valid. NET Framework component format string (for example, "original_{0}"). To indicate how the parameters in the OldValues and keys dictionaries are renamed to distinguish them from the newvalues parameters.

The following code example shows a typical SQL command used by the SqlDataSource Control in OverwriteChanges and CompareAllValues mode. The ID field is assumed to be the primary key field. Note that the next command compares all the original values of the data row in the WHERE clause, instead of just comparing the primary key. In this case, the oldvaluesparameterformatstring of the data source needs to be set to "original_{0}".

SELECT [ID], [Name], [address] from [Contacts]
--OverwriteChanges
UPDATE [Contacts] SET [Name] = @Name, [address] = @Address WHERE [ID] = @ID
DELETE from [Contacts] WHERE [ID] = @ID

--CompareAllValues
UPDATE [Contacts] SET [Name] = @Name, [address] = @Address WHERE [ID] = @original_ID
and [Name] = @original_Name and [address] = @original_Address
DELETE from [Contacts] WHERE [ID] = @original_ID and [Name] = @original_Name
and [Address] = @original_Address
Note that the insert operation does not require oldvalues,conflictdetection to be meaningful only for the update and delete operations.

The following example shows the behavior when a conflict occurs. To run this example, you have to open two instances of the example in two separate browser windows (two clicks "Run Sample"). Then click the "Edit" button on the same line on the two form to get the row into edit mode. Change a value in the first window and click "Update", please note that this update is successful. In the second window, enter a new value in the row and click "Update", which is unsuccessful because the value of the underlying data row has been changed by the first update operation. This example detects the AffectedRows property of the updated or deleted event argument, which confirms that the conflict occurred for 0.

<script runat= "Server" >
Protected Sub sqldatasource1_updated (sender as Object, E as SqlDataSourceStatusEventArgs)
If e.affectedrows = 0 Then
Response.Write ("Row changed, update aborted<br/>")
End If
End Sub

Protected Sub sqldatasource1_deleted (sender as Object, E as SqlDataSourceStatusEventArgs)
If e.affectedrows = 0 Then
Response.Write ("Row changed, delete aborted<br/>")
End If
End Sub
</script>
When update or delete uses the templated UI, the old values of the bidirectional (two-way) data-bound fields that use the BIND syntax are preserved. For delete, this means that you have to use BIND syntax for data-bound values in ItemTemplate in order to preserve the old values required for the deletion operation. The following example illustrates this technique.

<asp:gridview ... >
<Columns>
<asp:commandfield showdeletebutton= "true" showeditbutton= "true"/>
<asp:templatefield headertext= "ContactID" insertvisible= "False" sortexpression= "ContactID"
<ItemTemplate>
<asp:label id= "Label1" runat= "server" text= ' <%# ' Bind ("ContactID")%> ' > </asp:Label>
</ItemTemplate>
<EditItemTemplate>
<asp:label id= "Label3" runat= "server" text= ' <%# Eval ("ContactID")%> ' > </asp:Label>
</EditItemTemplate>
</asp:TemplateField>
<asp:templatefield headertext= "ContactName" sortexpression= "ContactName"
<ItemTemplate>
<asp:label id= "Label2" runat= "server" text= ' <%# ' Bind ("ContactName")%> ' > </asp:Label>
</ItemTemplate>
<EditItemTemplate>
<asp:textbox id= "TextBox1" runat= "server" text= ' <%# ' Bind ("ContactName")%> ' > </asp:TextBox>
</EditItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>

You can gently handle conflict detection errors by prompting the user to change the underlying data, displaying the changed values to the user, and letting the user choose to submit or discard their actions. The following example shows a possible way to handle conflict detection. Note that the DetailsView RowUpdated event parameter passes a dictionary that can be used to detect values entered by the user. You can also set the Keepineditmode property of this event parameter to allow the user to DetailsView in edit mode while deciding how to handle the conflict. This example tests the method similar to the one above, opening two windows to create a conflict update.

Protected Sub detailsview1_itemupdated (ByVal sender as Object, ByVal e As System.Web.UI.WebControls.DetailsViewUpdatedEventArgs)
If e.affectedrows = 0 Then
' Keep DetailsView in edit mode and synchronize with database
E.keepineditmode = True
Detailsview1.databind ()
　
' Repopulate DetailsView with values entered by the user
Dim T as TextBox
t = detailsview1.rows (1). Cells (1). Controls (0)
T.text = E.newvalues ("OrderDate")
t = detailsview1.rows (2). Cells (1). Controls (0)
T.text = E.newvalues ("ShipCountry")

Errorpanel.visible = True
Else
Errorpanel.visible = False
End If
End Sub

Protected Sub detailsview1_modechanging (ByVal sender as Object, ByVal e As System.Web.UI.WebControls.DetailsViewModeEventArgs)
If E.cancelingedit = True AndAlso errorpanel.visible = True Then
Errorpanel.visible = False
End If
End Sub
When using ObjectDataSource, the situation is similar. Note that because the ConflictDetection property of the data source is set to CompareAllValues, the data source looks for a updatecontact overload that accepts the original value of each field of the contact object.

You can also use both the DataObjectTypeName attribute and the compareallvalues. In this case, ObjectDataSource finds a updatecontact overload that accepts only two parameters (both contacts). The first parameter is the contact object that holds the new value, and the second parameter is the contact object that holds the old value.