Session State and Behavior of DataView

  • Thread starter Thread starter W.G. Ryan eMVP
  • Start date Start date
W

W.G. Ryan eMVP

I've found something that's really befuddled me. I'm storing a DataView in
Session state and when I call Delete on it (and I'm NOT calling
AcceptChanges on the underlying Datatable) - it's reducing the rows count:

Debug.WriteLine("COUNT Before: " +
((DataView)Session["WorkingData"]).Count.ToString()); //2
((DataView)Session["WorkingData"]).Table.Rows.Delete();
Debug.WriteLine("COUNT After: " +
((DataView)Session["WorkingData"]).Count.ToString()); //1

I've used the exact same code referencing the Table property of the DataView
and I get the same behavior.

Now, when I call Reject changes immediately afterward - I get 2 and 0
instead of 2 and 2 which is what I'd expect.

This is totally opposite to everythign I would expect. Same code in a
Winforms scenario works exactly as I'd expect however - so I'm guessing it's
related to Session state - but why? DataTables are serializable so WTF?
 
Ok - now I'm totally confused. I got rid of all of the references to the
DataView - just went directly w/ Datatable and the Exact same stuff happens.
I guess this isn't too surprising b/c I was referencing the view's Table
property - but I'm totally confused by this behavior -

Debug.WriteLine("COUNT Before: " +
((DataTable)Session["WorkingData"]).Rows.Count.ToString()); //2

((DataTable)Session["WorkingData"]).Rows.Delete();



Debug.WriteLine("COUNT After: " +
((DataTable)Session["WorkingData"]).Rows.Count.ToString()); //1
 
Uhhh - nevermind.

I changed the code to manually add the rows instead of using a DataAdapter
and I forgot to call AcceptChanges.
 
Hi Bill,

You always write that you in the beginning (like me therefore I remember it
me) used remove by accident. Maybe it is here in the right place.

:-)

Cor
 
Yep - I sure did. And this is the exact behavior I'd expect if I used
remove - but I was using delete, that was so weird. I got sidetracked b/c I
was using Session state and thought that may have been the cause - but when
I ran the 'same' code in a Winforms app - I was using the adapter to fill
the Table - which defaults to true on AcceptChangesDuringFill. I originally
had this set on my web app - filling via the adapter - but manually
populated a few rows for testing purposes.

I actually thought it was 'removing' instead of deleting based on the
behavior - so basically I spent two hours learning something I already
learned a few years ago about DataRowState - ;-)
 
Back
Top