Freeing memory used by old datarows

[Miha Markic]

Jon,

DataTable is keeping track of rows with an internal collection.
Even of those just created by NewRow and not yet Added.
Maybe the designers didn't foresee that one would use NewRow only for buffer
or cache.

The second thing is that if you delete (not remove) rows that are marked as
RowState=RowState.Added (thus before calling AcceptChanges) the row will be
ready for GC. Otherwise table keeps the row because it needs it for database
synchronizing.

Hope this explains something,

 

[Jon Skeet [C# MVP]]

DataTable is keeping track of rows with an internal collection.
Yup.

Even of those just created by NewRow and not yet Added.
Maybe the designers didn't foresee that one would use NewRow only for buffer
or cache.

The second thing is that if you delete (not remove) rows that are marked as
RowState=RowState.Added (thus before calling AcceptChanges) the row will be
ready for GC. Otherwise table keeps the row because it needs it for database
synchronizing.

Well, a row which hasn't been added at all shouldn't be needed for
database synchronization, should it?

This does seem to be a bit of a "gotcha" area.

 

[Miha Markic]

Well, a row which hasn't been added at all shouldn't be needed for
database synchronization, should it?

This does seem to be a bit of a "gotcha" area.

Yes, it is tricky because the table doesn't know that you won't add the row
to the table and at the same time it has to keep an eye on the row.
I think it should be handled within DataRow.Delete method (as for now it
simply returns when row hasn't been added).

 

[Leo Tohill]

Just to reinforce the point, note that if the application code drops all
references to the newRow (that was not added),
there is no way to regain a reference and add/delete it. These are
orphaned, inaccessible rows, which is pretty much like a memory leak.

I wonder why the table needs to "keep an eye on" the non-added rows?