Binder vs underlying DataTable

After I execute a DeleteRecordsAtRowIndex, my grid is correct and Binder.RecordCount is correct but if I look at the underlying datasource (dataset.datatable.count), it doesn''t reflect the deletion. Is there an additional command that I need to flush the changes into the datasource? Also, if I do a DeleteRecordsAtRowIndex, it doesn''t appear that anything gets written into the UndoStack. Is this an action that can''t be undone?

Undoing the deleting rows in a GridDataBoundGrid is not part of the standard undo support. I tried to see the problem you reported by adding a GridDataBoundGrid to form with a button and this handler. private void button1_Click(object sender, System.EventArgs e) { Console.WriteLine(dt.Rows.Count); this.gridDataBoundGrid1.DeleteRecordsAtRowIndex(1,1); Console.WriteLine(dt.Rows.Count); } dt is a DataTable that I had set to be the grid''s DataSource in formload. With this code I do not see a problem (using 2.0.5.1). Can you tell me how to see this problem in one of our samples, or can you post a sample project showing the problem?

Let''s see if this makes a difference ... In the Form constructor, I do the following : gridEvents.BeginUpdate(); gridEvents.Binder.SuspendBinding(); gridEvents.Binder.SetDataBinding(this.CaseDataSet.dsTimelineDatabase.CaseFact,null); gridEvents.Binder.ResumeBinding(); where CaseDataSet is a class, dsTimelineDatabase is a dataset and CaseFact is a datatable. The grid displays the correct information. If I start with two records and then delete one, Binder.RecordCount = 1 and this.CaseDataSet.dsTimelineDatabase.CaseFact.Count stays at 2.

Using this code to set the datasource does not show any problem for me. this.gridDataBoundGrid1.Binder.SetDataBinding(ds.Tables[dt.TableName], null); You can set gridEvents.DataSource = this.CaseDataSet.dsTimelineDatabase.CaseFact; and this would be what I tried first. Can you post a sample project that does not work? Is it possible the table you are removing rows from is different from the table you are checking the rowcount on?

I''m going to table this for now. It appears that the underlying table is being updated (the row is considered to be a "deleted row"). It is odd that our counts are different though. Will determine if this is a real issue when I implement the logic to flush the changes to the database.