DataView filter fails after insert

[Waxabi X]

I have created a filtered dataview and bound it to a datagrid. Based
on certain events within the program I change the DataView.Filter
property and the grid subsequently reflects the correct recordset.

When I insert a record into the filtered DataView using
DataView.AddNew(), the other records in the underlying DataTable are
appropriately filtered when a DataRow.Filter is applied but the new
record inserted is included in the DataView's filtered set regardless
of what the .Filter property is set to. In other words, the new record
will not filter out of the view. If I commit the change and refill the
dataset the new record exhibits the appropriate filtering behavior;
but this is an undesirable workaround for a variety of reasons.

Incidentally this is using the Oracle Data Provider (Oracle ODP
9.0.2). Is this a bug in ADO or the provider or is there a step I need
to take to keep this undesired behavior from happening that I am not
aware of?

 

[Cole]

I have used the DataView.AddNew with RowFilter before and it worked
correctly. However, I was not using a DataGrid (I don't see why this would
impact the DataView filter, but you never know). Have you tried re-setting
the filter?

grid.BeginUpdate();
string filter = DataView.RowFilter;
DataView.RowFilter = "";
DataView.RowFilter = filter;
grid.EndUpdate();

Something like that might work.

When you do a DataView.AddNew I believe that the underlying DataRow will
have a RowState = Detached, which has caused me issues in the past.

I have pretty much given up using the DataView's AddNew and Delete methods.
I get the underlying table and do all of my work on it. I have had much
more success with this approach.

Cole

 

[Waxabi X]

the filter?

To restate the issue: when the DataView.Filter is changed, records
added to the filtered view appear in the view whether they meet the
filter criteria or not.

I have pretty much given up using the DataView's AddNew and Delete methods.
I get the underlying table and do all of my work on it.

To the best of my knowledge, ADO refreshes data from the DataView back
to the DataTable but not from the DataTable down to the DataView. In
other words, if you make a change to the underlying datatable, the
DataViews are not automaticaly updated. Therefore the controls bound
to a view whose underlying DataTable is modified will become invalid.

 

[Cole]

To restate the issue: when the DataView.Filter is changed, records

added to the filtered view appear in the view whether they meet the
filter criteria or not.

I understand this. What I'm saying is that re-setting the filter *might*
cause the DataView to filter correctly. The reason I say this is that
setting the RowFilter = "" and then back to your original RowFilter will
causes a refresh of the DataView (I wish there was a DataView.Refresh). You
can look in the IL and see that when the index is regenerated when a new
filter is set. Inefficient? yes, but it works.

Cole

 

[Cole]

To the best of my knowledge, ADO refreshes data from the DataView back

to the DataTable but not from the DataTable down to the DataView. In
other words, if you make a change to the underlying datatable, the
DataViews are not automaticaly updated. Therefore the controls bound
to a view whose underlying DataTable is modified will become invalid.

I thought DataView's updated when the underlying table changed, but I wanted
to verify that before I responded. I did a small test and the DataView did
update the control when a record was simply added to the DataTable.Rows
collection.

Here is a scenario you can run to verify.

Create a form with a ListBox.
Create a DataView on a DataTable that has some records but no changes.
Then add a new row to the DataTable's RowCollection.
You will now see a new row in the ListBox.

Cole

 

[Waxabi X]

I tried setting the row filter to an empty string as you suggested and
unfortunately it did not correct the issue

 

[Waxabi X]

OK I think what I was really referring to was inserting in the
DefaultView did not update other views derived from the DefaultView. I
think I was incorrect in referring to this as "the underlying
DataTable". Once I get a chance to try your idea I will post the
result.