Selecting the wrong item because of old data in GridView

Question

I'm working in Visual Studio 2010 with C#/ASP.NET and a SQL server database. I'm trying to fix a website that will allow managers to assign employees to various tasks. The problem now is that if two managers are working at the same time, the wrong employee may be assigned to a task. The list of employees is represented in a gridview.

The problem seems to occur because one of the users is looking at old data in a gridview.

Let’s say that the first person loads the list and the GridView looks like this:

-Employee 1

-Employee 2

-Employee 3

-Employee 4

Then a second person comes in and makes an assignment to Employee 2, which removes Employee 2 from the list. The actual list now looks like this:

-Employee 1

-Employee 3

-Employee 4

But the first person still sees this because their page hasn’t updated yet:

-Employee 1

-Employee 2

-Employee 3

-Employee 4

The first person then tries to assign employee 3 to a task. They still see the old list. When they click to make the assignment, the page posts back to the server (apparently selecting a row in a gridview control is a server side event, so I’m not sure if there’s a way around this http://forums.asp.net/t/1706468.aspx/1). The page reloads and tries to do the postback event, checks and sees that the control is not yet valid (because databinding occurs after the postback event is supposed to be processed), so I think the postback event is delayed until after databinding. (Here’s the order of events on a page load http://msdn.microsoft.com/en-us/library/ms178472(v=vs.100).aspx) Once the gridview has been databound, the data is up to date like this:

-Employee 1

-Employee 3

-Employee 4

And then the postback event can be processed. The postback event contains the row index of the control that was selected. The third row was selected, so the postback event gets employee 4 (Who is now in the third row) from the grid. It then uses that information to get employee 4’s unique ID, when we wanted employee 3’s unique ID. How do we ensure that we get the correct employee’s ID in this situation?

The problem seems to be that the click is applied after the databinding occurs and changes the grid. I thought that preventing the page from doing postback would be a good thing to try, but the gridview operations are all server side so I don’t think I can do that. I don’t know of a way to preserve bound data through a postback, so every time we post back we are obliged to get new, potentially different, data. I feel like I’ve walked through most of the options, do you see anything wrong with my reasoning, or any suggestions for new things to try? Is there a way to get the employee ID before the page posts back?

The page works fine for just one user, the problem only occurs when multiple users are making changes at the same time.

Answer 1

I had to handle the databinding myself instead of using an ObjectDataSource to do it automatically.

Previously I had used the GridView's DataSourceID to link it to a datasource that would query the server for the data on every page refresh. The ObjectDataSource caused data to bind automatically. In order to get the additional control that I needed I had to handle all of the databinding in the code behind my page.

I did this by storing the gridview data in the viewstate, and loading the data from the viewstate on each page refresh. This way I could control when the gridview data got updated with the data in the database.

These two pages were quite helpful in bringing me to my answer:

DataBind and Postback

http://www.aarongoldenthal.com/post/2009/04/19/Manually-Databinding-a-GridView.aspx

Answer 2

You could enable ViewState for the control, so that the GridView data does not have to be reloaded during the PostBack.

Instead the control will remember the first loaded data during the PostBack and continue to work with that.

Of course that does not solve your problem with concurrency, for example if someone does something with an employee that is already deleted. In that case you would have to check the actual database again before executing the action and show an error/warning to the user if he is operating on old data.