The DataGrid server control is one of the most powerful—and most poorly documented—built-in features of the .NET Framework. Sure, getting the DataGrid to chew up and spit out your ADO.NET data is easy. But if you don’t properly understand its advanced workings, you’ll spend more than a few hours cursing your computer. For example, deleting data from a DataGrid is far from intuitive. To help you handle the task, I’ll show you how to quickly set up a DataGrid that has a delete button with a delete confirmation popup and explain how to process the delete command in the database.
Before you jump into the specifics of deleting from a DataGrid, you should have a working knowledge of how the DataGrid control works. If you don’t, you’ll find many Internet resources that will help you get up to speed. In particular, I recommend “An Extensive Examination of the DataGrid Web Control.” It’s a great jumping-off point.
We’re going to begin with a blank ASP.NET page. Add the code in Listing A to the HTML view.
As you can see, we’ve added a hidden column that will store the primary key for each record. This will allow us to do some work with the data later. So we have a basic DataGrid, but we still need to feed it data. Switch to the codebehind view and add the code in Listing B.
For this example, we’ll employ the trusty Northwind database to play with some data. For brevity, we’re calling the database directly from our codebehind, but usually, such commands are moved to the Data Access Layer for a completely modular design. (I’ll explain more about application architecture in a future article.) Compile and run the page, and you’ll see a basic, no-frills DataGrid.
In most real-world situations, however, users won’t just need to see data; they’ll need to work with it. So in Listing C, you’ll add a delete button to the last column in the grid by changing the <columns> section of the grid code.
As you can see, this code uses a template column with a button instead of a ButtonColumn. Why? It’s a purely semantic decision. If you want to later, you can add more buttons to the column in a similar fashion without having to rewrite a bunch of code. You can really go either way.
No delete button would be complete without a confirmation dialog box, so add Listing D code to the codebehind.
Obviously, we can’t do anything with the button until it has been created, and it won’t be created until the row is bound to the data. So we’ll employ the ItemDataBound event to trigger the addition of this code.
Compile and run the page. Now, when you click the delete button, you’ll get a dialog box confirming your request. Click Cancel, and the postback event will not fire. Click OK, and the form will be submitted. Right now, however, nothing will happen, because we haven’t coded the event handler yet. Let’s change the codebehind to handle the ItemCommand event.
In Listing E, the hidden ID column identifies which database item will be deleted. As I mentioned earlier, the actual delete processing should be contained in a separate set of classes for data access. Further, you should never use direct operations on a database, as they leave you open to SQL injection attacks.
The ItemCommand approach is more than adequate if you’re working with only one type of grid command. Things get a little trickier when you add paging functionality to the mix. Regardless of whether the default or custom paging modes are used, the page links are actually LinkButton objects, which are added programmatically. This means that they respond to ItemCommand events like any other LinkButton. Future articles will dive deeper into the DataGrid and look at implementing the not-so-automatic built-in paging system.
Although a DataGrid with a delete button may be a common feature request, it can be a little tricky to create one and to process the command against the database. However, mastering such advanced DataGrid techniques is worth the effort. Once you do, you’ll discover how versatile DataGrids can be.