I always was suspicious about using ObjectDataSource as data source for ASP.NET 2.0 controls. It saves you some C# (or VB.NET) coding, but adds lots of automatically generated ASPX stuff, which is hard to maintain. Plus flexibility of the code is just not there.
Now I have another good reason not to use ObjectDataSource and automatic binding, because such approach has serious concurrency issues.
Basically if two users are using the same page simultaneously, they could delete rows which they didn’t intend to delete.
This ugly bug caused by the fact that datagrid is trying to delete rows based on row index, not based on row ID.
Read more details about the issue in: Concurrency issues with GridView by jdcrutchley.
Scott Mitchell provides a workaround (hack) to this problem, so you still can use ObjectDataSource. However the need of using hacks just kills the whole idea of using ObjecDataSource with automatic GridView binding. The advantage was to make coding easier. Now the coding with ObjecDataSource is getting more complex than straitforward approach which I like to use:
<asp:GridView ID="gridView" runat="server" AutoGenerateColumns="false">
<asp:LinkButton ID="Delete" runat="server" Text="Delete" OnCommand=" Delete_Command" CommandArgument='<%# Eval("RowId") /%>' />
protected void Page_PreRender(object sender, EventArgs e)
gridView.DataSource = MyBusinessClass.GetMyData();
protected void Delete_Command(object sender, CommandEventArgs e)
int rowId = int.Parse(e.CommandArgument);
- December (2)
- November (2)
- October (5)
- September (1)
- August (7)
- July (4)
- June (7)
- May (3)
- April (5)
- March (1)
- February (5)