I have a program that invokes the following block of code every x
seconds. The process private bytes keeps increasing after every call.
I've try to dispose the SQlDataAdapter in the finally block, but did
not work. If I invoke the garbage collector manually GC.Collect in the
finally block, there is no more memory leak. What's wrong with the
following block of code? Is there a real leak or am I missing
something?

I've been working on this for few days, but I cannot figure it out.
Please help!

private DataSet GetJobQ()
{
DataSet ds = new DataSet();
SqlConnection conn = new SqlConnection( "myconnectionstring" );
SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );

try
{
adpt.Fill( ds );
}
finally
{
con.Close();
}
return ds;
}

Re: memory leak in SqlDataAdapter.Fill method? by Alex

Alex
Tue Apr 05 10:54:16 CDT 2005

What is happening with the data set you are returning? Is it being merged
with another set? If the data set data is incrementally populating some grid
control for example you should expect the data from the database to take up
memory incrementally.

"Ben" <benoit.leclerc@bell.ca> wrote in message
news:29f894de.0504050729.18bbee01@posting.google.com...
>I have a program that invokes the following block of code every x
> seconds. The process private bytes keeps increasing after every call.
> I've try to dispose the SQlDataAdapter in the finally block, but did
> not work. If I invoke the garbage collector manually GC.Collect in the
> finally block, there is no more memory leak. What's wrong with the
> following block of code? Is there a real leak or am I missing
> something?
>
> I've been working on this for few days, but I cannot figure it out.
> Please help!
>
> private DataSet GetJobQ()
> {
> DataSet ds = new DataSet();
> SqlConnection conn = new SqlConnection( "myconnectionstring" );
> SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
>
> try
> {
> adpt.Fill( ds );
> }
> finally
> {
> con.Close();
> }
> return ds;
> }



RE: memory leak in SqlDataAdapter.Fill method? by MatthewHolton

MatthewHolton
Tue Apr 05 11:05:02 CDT 2005

Ben,

I would place clean up code in the finally block or inside of your try.

private DataSet GetJobQ()
{
try
{

#region Prepare the objects
DataSet ds = new DataSet();
SqlConnection conn = new SqlConnection( "myconnectionstring" );
SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
#endregion

#region All 'opens' should use 'close' Cleanup
con.Close();
#endregion

#region Inner Try
try
{
adpt.Fill( ds );
}
catch (SQlException ex)
{
//Determine if you can handle this exception here
//otherwise rethrow the exception
}
#endregion

}
catch (exception e)
{
//Determine if you can handle this exception here
//otherwise rethrow the exception
}
finally
{

#region Release Objects
conn = null;
adpt = null;
#endregion

}

return ds;

}



private DataSet GetJobQ()
{
DataSet ds = new DataSet();
SqlConnection conn = new SqlConnection( "myconnectionstring" );
SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );

try
{
adpt.Fill( ds );
}
finally
{
con.Close();
}
return ds;
}


"Ben" wrote:

> I have a program that invokes the following block of code every x
> seconds. The process private bytes keeps increasing after every call.
> I've try to dispose the SQlDataAdapter in the finally block, but did
> not work. If I invoke the garbage collector manually GC.Collect in the
> finally block, there is no more memory leak. What's wrong with the
> following block of code? Is there a real leak or am I missing
> something?
>
> I've been working on this for few days, but I cannot figure it out.
> Please help!
>
> private DataSet GetJobQ()
> {
> DataSet ds = new DataSet();
> SqlConnection conn = new SqlConnection( "myconnectionstring" );
> SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
>
> try
> {
> adpt.Fill( ds );
> }
> finally
> {
> con.Close();
> }
> return ds;
> }
>

Re: memory leak in SqlDataAdapter.Fill method? by Miha

Miha
Tue Apr 05 11:16:41 CDT 2005

Hi Ben,

As GC runs on non-deterministic times it is normal that memory increases
until GC runs.
Your code is fine and you even don't need explicit close as it is handled by
Fill method in this case.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

"Ben" <benoit.leclerc@bell.ca> wrote in message
news:29f894de.0504050729.18bbee01@posting.google.com...
>I have a program that invokes the following block of code every x
> seconds. The process private bytes keeps increasing after every call.
> I've try to dispose the SQlDataAdapter in the finally block, but did
> not work. If I invoke the garbage collector manually GC.Collect in the
> finally block, there is no more memory leak. What's wrong with the
> following block of code? Is there a real leak or am I missing
> something?
>
> I've been working on this for few days, but I cannot figure it out.
> Please help!
>
> private DataSet GetJobQ()
> {
> DataSet ds = new DataSet();
> SqlConnection conn = new SqlConnection( "myconnectionstring" );
> SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
>
> try
> {
> adpt.Fill( ds );
> }
> finally
> {
> con.Close();
> }
> return ds;
> }



RE: memory leak in SqlDataAdapter.Fill method? by NoSpamMgbworld

NoSpamMgbworld
Tue Apr 05 12:47:05 CDT 2005

Use Dispose() and be patient, as GC runs on its own (may not see instant
memory release).


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

"Ben" wrote:

> I have a program that invokes the following block of code every x
> seconds. The process private bytes keeps increasing after every call.
> I've try to dispose the SQlDataAdapter in the finally block, but did
> not work. If I invoke the garbage collector manually GC.Collect in the
> finally block, there is no more memory leak. What's wrong with the
> following block of code? Is there a real leak or am I missing
> something?
>
> I've been working on this for few days, but I cannot figure it out.
> Please help!
>
> private DataSet GetJobQ()
> {
> DataSet ds = new DataSet();
> SqlConnection conn = new SqlConnection( "myconnectionstring" );
> SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
>
> try
> {
> adpt.Fill( ds );
> }
> finally
> {
> con.Close();
> }
> return ds;
> }
>

Re: memory leak in SqlDataAdapter.Fill method? by Miha

Miha
Tue Apr 05 13:11:09 CDT 2005

Right, he should use Dispose (even if does nothing in this case).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote
in message news:89D51060-7F28-4807-B1BB-BA5608EE4AB7@microsoft.com...
> Use Dispose() and be patient, as GC runs on its own (may not see instant
> memory release).
>
>
> ---
>
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> ***************************
> Think Outside the Box!
> ***************************
>
> "Ben" wrote:
>
>> I have a program that invokes the following block of code every x
>> seconds. The process private bytes keeps increasing after every call.
>> I've try to dispose the SQlDataAdapter in the finally block, but did
>> not work. If I invoke the garbage collector manually GC.Collect in the
>> finally block, there is no more memory leak. What's wrong with the
>> following block of code? Is there a real leak or am I missing
>> something?
>>
>> I've been working on this for few days, but I cannot figure it out.
>> Please help!
>>
>> private DataSet GetJobQ()
>> {
>> DataSet ds = new DataSet();
>> SqlConnection conn = new SqlConnection( "myconnectionstring" );
>> SqlDataAdapter adpt = new SqlDataAdapter( "EXEC GetJobQ", conn );
>>
>> try
>> {
>> adpt.Fill( ds );
>> }
>> finally
>> {
>> con.Close();
>> }
>> return ds;
>> }
>>



Re: memory leak in SqlDataAdapter.Fill method? by benoit

benoit
Wed Apr 06 12:13:41 CDT 2005

Invoking the Dispose() function solve the problem, the memory tend to
stabilize after a certain amount of time (the time the GC does his
work).

Thank's