Sep 1, 2007

Object DataSource Update

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"];
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(); } }