I have a delete button which does this:

TTDataSet.PunchEventTable.Rows(dgvData.SelectedRows(0).Index).Delete()

The problem is that if I delete row 0 (the 0th index in the DataGridView and in the underlying table, all is well. But now row 1 in the table corresponds to row 0 in the DataGridView, so if I run that code to delete a row again, nothing happens because row 0 in the table is already deleted.

I tried

PunchEventTableBindingSource.EndEdit()
and
TTDataSet.PunchEventTable.AcceptChanges()

after the call to delete, but neither seems to fix the problem. Of course the problem is fixed once Update is called on the DataAdapter, but I didn't want to do that until all of the changes were made, this way I could cancel the changes if the user so wishes.

Is there a way to fix this?

Thanks,

Dave

Dani AI

Generated

A quick diagnosis and practical follow‑ups based on this thread.

The root cause in cases like 's is binding the grid to a snapshot (a static collection) instead of a live view. When the grid shows rows from a snapshot, the displayed row indexes can drift away from the DataTable.Rows collection after deletes, filters, or sorts. That mismatch is why deleting "row 0" in the grid later targets the wrong underlying row. Switching the UI to use a live, data‑bound view keeps each displayed row mapped to its underlying record and avoids index drift.

How to think about it and what to do differently

  • Use a binding layer that exposes live row objects (so each visible row corresponds to a DataRowView/currency manager item). Rely on the binding layer's current item or position to identify the record to remove, rather than translating DataGridView.SelectedRows indexes into DataTable row indexes.
  • Understand the difference between marking and removing: marking a row as deleted preserves change information so you can later persist or roll back; immediate removal deletes it permanently from the in‑memory table.
  • For "cancel changes" support, keep a pre‑edit snapshot of the table (a Copy) or use the table's rollback mechanism so you can revert pending deletes before you call the persistence step.

Troubleshooting checklist

  • If the UI does not update, force the binding to refresh (use the binding layer's reset/refresh methods or ensure EndEdit has been called).
  • If you want to persist changes, call the data adapter's update routine (it works from row states); avoid calling methods that clear change state prematurely.
  • If deletes still appear to be targeting the wrong record, confirm you are addressing the binding layer's current item and not translating grid row indexes into table indexes when filters/sorts are in effect.

Thanks to for posting the fix that exposed the underlying mapping issue, and to for prompting investigation of row/state handling.

Recommended Answers

All 5 Replies

I see you've posted this on the vbforums website as well. I don't post over there but it doesn't look like you've gotten your answer yet either. I have two possible suggestions for you

One is to reset the row numbers with something like this

For i = 0 To newRow.ItemArray.Length - 1
      currentRow(i) = newRow(i)
      Next

( I found that on experts-exchange - if you scroll to the bottom the solutions are there but he was having a different problem than you)

http://www.experts-exchange.com/Programming/Languages/.NET/Visual_Studio_.NET_2005/Q_22924060.html

The other suggestion is to look at .acceptchanges

possibly http://msdn.microsoft.com/en-us/library/system.data.dataset.acceptchanges.aspx and reset the database

So you can actually change the row index of a row in a table?

I mentioned I tried calling acceptchanges after deleting the row with no change, which does seem odd?

looks like it, although I have not done this myself - type"

"VB.NET WinForms - DataGridView - Adding new rows, removing old ones to AcceptChanges"

in google and it's the first entry, you can then scroll down to the bottom and see the accepted solution. (it's a long scroll down)

for some reason the accepted solution is blocked when you post the link somewhere

I got it to work... shouldn't have been this difficult to figure out.

The key was to use the filter() method of the binding source, rather than setting the DataGridView datasource to the select() method of the datatable.

PunchEventTableBindingSource.Filter = FilterString
 PunchEventTableBindingSource.Sort = SortString

Then I can delete a row like this:

DirectCast(PunchEventTableBindingSource.Current, DataRowView).Delete()

Hmm, thanks for posting your solution. That should help

would you mind marking it as solved so others can find the answer?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.