Practical ASP.NET

Handling Update Exceptions in the DataView Events

Peter shows a "code-lite" way to handle exceptions when using DataView to update data.

• By Peter Vogel
• 08/06/2008

In the introductory course on ASP.NET that I wrote for Learning Tree International, we eventually come to the moment when we display data in a page. The students drop a DataSource and a DataView on the page, configure the two objects, and retrieve the data.

The only problem is that there will be at least one student in each class who will complain that "I didn't get to write any code -- we just used the Wizards."

Unless you're paid by the hour, it's not clear to me why this is a bad thing: The less code I write, the less likely I am to introduce a new bug.

More critically, the complaint reflects a fundamental misunderstanding of the ASP.NET 2.0 paradigm: Configure components to get base behavior and write code only for your special needs.

To placate my unhappy students, I usually show them how to write code to handle truly "special events": exceptions when updating data with the DataView.

Exploiting DataView Events
The DataView controls fire events both before and after each data access activity. The event names are similar among all the DataViews (GridView, FormView, DetailsView, etc.). A Deleting event before any deletions/a Deleted event after the deletion; an Updating event before updates/an Updated afterward, and so on.

One of my gurus, Ken Getz, refers to these as the "gerund events" and the "past participle events." I refer to them as the *ing events and the *ed events. I think my terms are more helpful but you're welcome to your opinion.

The *ing events are useful for preventing problems; anything you can do there to detect bad data means one less trip to the database server and faster feedback to your users. But the *ed events on the DataViews are where you'll handle problems when something goes awry.

The e parameter on those events provides five really useful features: access to any Exception object raised during the data access, a flag to keep the DataView in edit or insert mode, the number of records changed (primarily useful if you're using the SqlDataSource), and a flag to tell ASP.NET that you've taken care of any problems.

When I write an *ed event, I first check to see if there was an error during the update by checking the e parameter's Exception property. If there is an Exception object with an error that I'm willing to handle, I do the decent thing and display the error message from the Exception object to the user. I also usually keep the DataView in change mode by setting the e parameter's KeepInEditMode (in Updated events) or KeepInInsertMode (in Inserted events) property to True. This gives the user another chance to enter their change (the user can always click the Cancel button to get out). I also set the e parameter's ExceptionHandled property to True because if I don't, the error will propagate up through the calling modules and ASP.NET may terminate my application.

If I'm not willing to handle the exception, I do nothing: The ExceptionHandled property defaults to False so the error will just move on up until some component takes care of it.

If I don't have an Exception, I still check to see if any records were updated by looking at the e parameter's AffectedRows property. If the AffectedRows property is 0, then it probably means that my user's data was changed after the user retrieved it and I used optimistic currency to skip the update (see my column on optimistic currency, "Handling Data Contention with Optimistic Concurrency"). For me, the right thing to do when someone else has changed the data is to re-DataBind the associated DataView to let the user see the latest data.

Putting it all together, the essential *ed event code looks like this.

Sadly, these eight lines of code usually aren't enough to satisfy my code-hungry students. They still go out of the room grumbling that all I've shown them is how to work with the Wizards and, now, how to fiddle with properties.