错误的行在绑定到DataAdapter的DataGridView中被删除

Question

Situation :

I'm writing a Winforms app using C# in VS2013 with .NET4.0.

I have a datagridview which I bind to a DataAdapter linked to a MySQL table. I'm performing updates using the DataAdapter's Update method. Due to the unconventional handling of dates and booleans in the MySQL table I set my own SQL commands rather than using CommandBuilder. These are fed by parameters set before calling Update. I call Update on RowValidated.

For inserting and amending this works fine.

Issue :

In the datagridview, when the user selects a single row, I want them to be able to hit delete and have the row removed from both the grid and the database. When I try this the row disappears from the datagridview and of course the cursor moves to a different row. But the database row that gets deleted is the new datagridview row that the cursor has fallen on. This is almost certainly because I use datagridview.CurrentRow to set the parameter for the delete command and I assume that at this stage the current row has indeed changed.

Question :

How do I amend this arrangement so the delete will work correctly? Clearly the underlying issue is that the row has disappeared from the grid before the database update takes place but I'm not sure how to resolve that. I suspect the solution may lie in handling things through different events but I'm not sure which.

Answer 1

Ok generating the SQL Delete command doesn't work when I reference CurrentRow from the dgv because by the time I'm building my parameters and doing the adapter.Update that dgv row has gone. That's why I end up deleting the wrong row. So I've solved it like this:

• In the UserDeletingRow event I'm storing the primary key value for the row being deleted.
• In RowValidated, where I call the adapter.Update I first use the stored primary key to build the correct SQL Delete command. Even though the row has already gone from the dgv the database delete now works correctly.

Relieved to get this working but this does seem like a pretty inelegant solution. Grateful if anyone knows of a slicker way of handling this. I'd be intrigued to know just what logic the CommandBuilder would have used. (Sadly I can't use CommandBuilder because my Inserts and Updates need to do Unix_TIMESTAMP conversions).