Assume you create a grid
that shows a list of EmployeeDetails objects. You also add a column with edit links. When the user
commits an edit, the GridView fills the ObjectDataSource.UpdateParameters collection with one
parameter for each property of the EmployeeDetails class, including EmployeeID, FirstName,
LastName, and TitleOfCourtesy. Then, the ObjectDataSource searches for a method named
UpdateEmployee() in the EmployeeDB class. This method must have the same parameters, with
the same names.
That means this method is a match:
public void UpdateEmployee(int employeeID, string firstName, string lastName,
string titleOfCourtesy)
{ ... }
This method is not a match, because the names don’t match exactly:
public void UpdateEmployee(int id, string first, string last,
string titleOfCourtesy)
{ ... }
This is not a match, because there’s an additional parameter:
public void UpdateEmployee(int employeeID, string firstName, string lastName,
string titleOfCourtesy, bool useOptimisticConcurrency)
{ ... }
The method matching algorithm is not case-sensitive, and it doesn’t consider the order or data
type of the parameters. It simply tries to find a method with the right number of parameters and the
same names. As long as that method is present, the update can be committed automatically, without
any custom code.
Sometimes you may run into a problem in which the property names of your data class don’t
exactly match the parameter names of your update method. If all you need is a simple renaming
job, you need to perform the task that was described in the “Updating with Stored Procedures”
section earlier, although the syntax is slightly different.
First, you define the additional parameters you need, with the correct names. For example,
maybe you need to rename the EmployeeDetails.EmployeeID property to a parameter named id
in the update method. Here’s the new parameter you need:
Second, you react to the ObjectDataSource.Updating event, setting the value for these parameters
and removing the ones you don’t want:
protected void sourceEmployees_Updating(object sender,
ObjectDataSourceMethodEventArgs e)
{
e.InputParameters["id"] = e.InputParameters["EmployeeID"];
e.InputParameters.Remove("EmployeeID");
}
Handling Identity Values in an Insert
So far, all the examples you’ve seen have used parameters to supply values to an update operation.
However, you can also create a parameter to return a result. With the SqlDataSource, you can use
this option to get access to an output parameter. With the ObjectDataSource, you can use this technique
to capture the return value.
To see this in action, it’s worth considering the InsertEmployee() method, which adds an
employee record and returns the newly generated unique ID value as an integer:
public int InsertEmployee(EmployeeDetails emp)
{ ... }
You don’t need to use the identity value. As you’ve seen already, linked data controls are bound
after any updates are committed, which ensures that the updated information always appears in
the linked controls. However, you might want to use the identity for another purpose, such as displaying
a confirmation message. To capture this identity value, you need to define a parameter:
Now you can retrieve the parameter by responding to the Inserted event, which fires after the
insert operation is finished:
protected void sourceEmployees_Inserted(object sender,
ObjectDataSourceStatusEventArgs e)
{
if (e.Exception == null)
{
lblConfirmation.Text = "Inserted record " + e.ReturnValue.ToString();
}
}
