>Hi Einar
> This information didnt come from an article. I found out about this with an application that I developed that runs 24/7. It started with 25MB usage and slowly climbed to 150MB+
>
Rodman,

FYI, there are a few circumstances that could cause .NET to retain the allocated memory of the DataTable for a very long time.

One of them is if the DataTable is not Cleared before removing it from the DataTables collection while there are any references to any objects below the DataTable in the pointer tree. The references are not automatically voided by .NET until the GC attempts to free the heap space of the object containing the reference. This object may have already been promoted to gen1 or gen2 before this check occurs, which means that it will not be checked until gen0 runs out of space (see below).

Another is if you have overridden the Finalize method of any object in the DataTable's pointer tree. If there is code in there, the DataTable will not be released until the code is executed. In combination with the longevity of the DataSet and its propensity for being promoted to the gen2 heap, this will tie up that memory for a long time.

Another is that since the DataSet is long-lived, it will eventually be promoted to the gen2 heap, which is only collected when an allocation request comes in with the gen0 & gen1 heaps still full after their respective cleanups. This may not happen for a long, long time.

>When I changed the code to re-create the dataset the mem probs went away
>

It's a good idea to use DataSet.Copy when you remove a DataTable from the collection. E.g., remove the DataTable from the collection, copy the entire DataSet to a temporary variable, assign the temporary variable to the old variable, then release the temporary variable.

This will put the new DataSet into the gen0 heap and ensure that there are no references to the old DataSet remaining. The memory will not be released immediately, but it will definitely be released the next time the gen2 heap is collected.

- Keith