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.
Exploiting the DataView events means less work for you and more robust code
in your application. Just don't be afraid to write less code.
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.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.