Pretty straight forward question, right? I'm asking because this is one of
the recommendations I'm getting from VSTS code analysis.

My problem is that I have a pattern of code sprinkled throughout much of
my business layer where data access code calls static methods that, in turn,
call stored procedures that read the selected data into newly created DataTables
and return these tables. It might be difficult to track and dispose of all
these tables.

So, how leaky are undisposed of DataTables?

Currently you probably don't need to.
However, it is recommended that you dispose everything that implements
IDisposable.

--
Miha Markic [MVP C#]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

"David Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Pretty straight forward question, right? I'm asking because this is one of
> the recommendations I'm getting from VSTS code analysis.
>
> My problem is that I have a pattern of code sprinkled throughout much of
> my business layer where data access code calls static methods that, in
> turn, call stored procedures that read the selected data into newly
> created DataTables and return these tables. It might be difficult to track
> and dispose of all these tables.
>
> So, how leaky are undisposed of DataTables?
>
>

David,

>
> So, how leaky are undisposed of DataTables?
>
You don't have to dispose anything that has no unmanaged resource.

AFAIK are there in ADONET no unmanaged resources involved

The purpose of managed code is to do the releasing for you at the best
moment.

Cor

But we're told to always Dispose of connections, so there must be some unmanaged
resources involved. I create all connections in "using" blocks. DataTables,
on the other hand, are often returned from methods, passed in as parameters,
real-bound to grids, and fake bound to trees (fake because there is no databinding,
just looping over the table and creating nodes)

I would say that is really a matter of debate. In fact, there have been a
lot of debates over whether or not connections really need to be disposed,
or if just closing is enough. So I don't think you can state this as a
matter of fact.

"David Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> But we're told to always Dispose of connections, so there must be some
> unmanaged resources involved. I create all connections in "using" blocks.
> DataTables, on the other hand, are often returned from methods, passed in
> as parameters, real-bound to grids, and fake bound to trees (fake because
> there is no databinding, just looping over the table and creating nodes).
>
>

No you don't. I think DataTable constructor have GC.SuppressFinalize(this)
anyway .. (I think .. I could be wrong).
Obviously don't keep 'em around eatin' memory.

- SM

"David Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Pretty straight forward question, right? I'm asking because this is one of
> the recommendations I'm getting from VSTS code analysis.
>
> My problem is that I have a pattern of code sprinkled throughout much of
> my business layer where data access code calls static methods that, in
> turn, call stored procedures that read the selected data into newly
> created DataTables and return these tables. It might be difficult to track
> and dispose of all these tables.
>
> So, how leaky are undisposed of DataTables?
>
>

David Smith wrote:

> Pretty straight forward question, right? I'm asking because this is
> one of the recommendations I'm getting from VSTS code analysis.
>
> My problem is that I have a pattern of code sprinkled throughout much
> of my business layer where data access code calls static methods
> that, in turn, call stored procedures that read the selected data
> into newly created DataTables and return these tables. It might be
> difficult to track and dispose of all these tables.
>
> So, how leaky are undisposed of DataTables?

Well, they seem to stay around for quite a while. Just try to
implement calling dispose on a couple of them which are used very
frequently. My tests show that the memory footprint of a large asp.net
application was much lower after I did that (and I used the datatables
in the same way as you do: call a DAL class, that one creates a
datatable, the returned datatable is bound to a repeater etc.). Which
was strange, because the Dispose method in a datatable didn't do much.

It's often impossible to call Dispose on all your data-access code, at
least in some situations.

Do some profiling with the performance monitor of windows and teh .NET
CLR counters available to you and see if it makes a difference, I saw
big differences, but it could be related to the databinding scenario I
used, as binding a datatable to a repeater creates a dataview under the
hood.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Marina wrote:

> I would say that is really a matter of debate. In fact, there have
> been a lot of debates over whether or not connections really need to
> be disposed, or if just closing is enough. So I don't think you can
> state this as a matter of fact.

There's no standard, especially for data-access related components.
SqlClient's SqlConnection.Dispose for example also takes care of the
associated SqlCommand objects (which don't need dispose really).

Oracle's ODP.NET doesn't do that: OracleConnection.Dispose doesn't
clean up OracleCommand objects associated with the connection. More
importantly: OracleParameter has a Dispose method as well, which IS
required.

I can see optimization paths if you see Dispose and Close as 2
different things: Close can mean: no longer needed, but keep the
resources around so when I open the connection again, they're available
for me. If Close means Dispose, those resources are gone and the
connection Open will be slower. This is all low-level stuff, but in
some scenario's it might be more efficient to use close instead of
dispose, IF the client supports different behavior of course.

FB

>
> "David Smith" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > But we're told to always Dispose of connections, so there must be
> > some unmanaged resources involved. I create all connections in
> > "using" blocks. DataTables, on the other hand, are often returned
> > from methods, passed in as parameters, real-bound to grids, and
> > fake bound to trees (fake because there is no databinding, just
> > looping over the table and creating nodes).


--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Frans,

> Well, they seem to stay around for quite a while. Just try to
> implement calling dispose on a couple of them which are used very
> frequently. My tests show that the memory footprint of a large asp.net
> application was much lower after I did that

IMHO is that not direct an advantage.

It is an advantage as a system keeps as much handles and memory available as
is needed for the processing.

If with keeping (while not needed) the memory low any processing time is
spent, than it is for me even a disadvantage.

However as said, just my opinion.

Cor