I was recently working on a "bug" in an inherited piece of software.  It's a web application that makes heavy use of GridView.  The bug is simple to reproduce:

1. Log on to the application.
2. Navigate to blurb page using menu.
3. Click the edit button on a row.
4. Click change date completed button in column Data Completed.
5. Select a new date completed from the pop up calendar.
6. When popup returns, web page repaints and row has disappeared!

Well, everything is as it appears in the steps to reproduce, unless you look a little closer.

It turned out that the GridView data source was sorted on the Date Completed column.  This was done so that all rows with an empty Date Completed column floated to the top of the grid for easy data entry.  However, once the date was edited, the code behind issued a GridView.DataBind() method  call. This forced a repaint (and a re-sort).  The rows are reordered and the currentRow marker is no longer valid for the grid.  (In fact, the currentRow was sorted to a different page in the GridView.)

The moral of the story is as follows:
If you are going to set up editing of grid rows and you are sorting the data, be prepared for odd behavior if someone changes the data in the sort key column.  In my case, the application attempted to repaint active update and cancel buttons on an incorrect row, further confusing the user.

My solution to the bug:
Change the data source sort clause and do not use the Data Completed column for ordering rows.

This is why I prefer a much older and less snazzy form of update on my web forms:

1. Click on a row.
2. Display an edit panel and populate controls with data from the grid row.
3. Do not allow direct editing in the grid. (I know, this is grid sacrilege.)
4. When the data is submitted, rebind the data to the grid and hide the edit panel.
5. This technique stops all sorts of grid scrolling and current/active row problems.