473,326 Members | 2,732 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Question about Dispose

Hi,

My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?

Bob Lehmann

Nov 18 '05 #1
17 1662

"Bob Lehmann" <none> wrote in message
news:OK**************@TK2MSFTNGP10.phx.gbl...
Hi,

My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?

Bob Lehmann


This is done because the Open method is inside the Try block and in the Finally
block you have no idea whether or not the connection opened successfully. What
if the connection opened but there's a bug in the connection itself? If you call
close you may get an error, or any other method may throw an exception.

Dispose makes sure the connection is properly closed prior to the object being
destroyed. This is a proper technique used to ensure that whether or not the
connection was opened, it will be closed before the end of the Try...Finally
block has been closed.

Make sense?

Mythran
Nov 18 '05 #2
<"Bob Lehmann" <none>> wrote:
My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?


I believe this is correct. I don't think there's any advantage in
calling Close() over calling Dispose().

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 18 '05 #3
Hi Bob Lehmann,

You are correct.

The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise
to call Dispose() unless you want connection to be removed from the
connection pool.

Regards
Ashish M Bhonkiya

"Bob Lehmann" <none> wrote in message
news:OK**************@TK2MSFTNGP10.phx.gbl...
Hi,

My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?

Bob Lehmann

Nov 18 '05 #4
Thanks, Jon.

So, is there any reason to *ever* use Close() instead?

Bob Lehmann

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<"Bob Lehmann" <none>> wrote:
My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?


I believe this is correct. I don't think there's any advantage in
calling Close() over calling Dispose().

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 18 '05 #5

"Bob Lehmann" <none> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...
Thanks, Jon.

So, is there any reason to *ever* use Close() instead?

Bob Lehmann


Yes, quoted from Ashish:

"The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise
to call Dispose() unless you want connection to be removed from the
connection pool."
That about sums it up :)

If you are worried about connection pooling, you will want to not use
Try...Finally and Dispose(). You will use Try...Finally and then check to see if
1.) the connection exists 2.) it's open 3.) call Close().

Hope this helps :)

Mythran
Nov 18 '05 #6
Ashish M Bhonkiya <bh******@hotmail.com.nospam> wrote:
You are correct.

The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise
to call Dispose() unless you want connection to be removed from the
connection pool.


Any evidence for this? I've heard talk of it before, but thought that
someone had disproved it in the same thread. It would certainly seem an
odd decision to make, as in languages such as C# with its "using"
statement, Dispose() is the most natural method to call.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 18 '05 #7
Mythran <ki********@hotmail.com> wrote:
So, is there any reason to *ever* use Close() instead?
Yes, quoted from Ashish:

"The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise
to call Dispose() unless you want connection to be removed from the
connection pool."

That about sums it up :)


Well, if it's correct. I have some doubts about it, to be honest.
If you are worried about connection pooling, you will want to not use
Try...Finally and Dispose(). You will use Try...Finally and then check to see if
1.) the connection exists 2.) it's open 3.) call Close().


Why would MS make life so hard for developers, relatively speaking?
It's much easier just to call Dispose(), and C# encourages this
practice with the "using" statement.

Anyone have appropriate experience which would allow them to easily
test this? While I have SQL Server on my laptop, I'm not convinced I
would know how to really *reliably* test this. I'll have a go though :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 18 '05 #8
OK - got it.

Thanks,
Bob Lehmann

"Mythran" <ki********@hotmail.com> wrote in message
news:#2**************@TK2MSFTNGP12.phx.gbl...

"Bob Lehmann" <none> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...
Thanks, Jon.

So, is there any reason to *ever* use Close() instead?

Bob Lehmann
Yes, quoted from Ashish:

"The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good

practise to call Dispose() unless you want connection to be removed from the
connection pool."
That about sums it up :)

If you are worried about connection pooling, you will want to not use
Try...Finally and Dispose(). You will use Try...Finally and then check to see if 1.) the connection exists 2.) it's open 3.) call Close().

Hope this helps :)

Mythran

Nov 18 '05 #9
mikeb wrote:
Bob Lehmann wrote:
Hi,

My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?

The Dispose() method in SqlConnection() checks the current state of the
connection, and calls Close() if it's open. Nothing more.


After reading Scott Allen's post elsewhere in this thread, I have to
correct my above statement: Dispose() does set the SqlConnection
object's connection string to null (which Close() does not seem to do).

This means that a connection that has been closed using Close() can be
reopened. A connection that has been closed using Dispose() cannot
without reinitializing the connection string. I don't think this
affects the pooling algorithm one way or another.

However, continuing to use a disposed object is probably not a good
practice in general (operations on a disposed object should result in
ObjectDisposed exception).

Close() makes the same check (ie., it's safe to close a connection that
is not open), so the check in Dispose() is not really necessary.

The Framework docs have advice on Dispose() vs. Close() naming:

-------------------------------------------------------------
For types where calling a Close method is more natural than calling a
Dispose method, add a public Close method to the base type. The Close
method in turn calls the Dispose method without parameters, which
performs the proper cleanup operations.
-------------------------------------------------------------

Essentially, a Close() method should have the same behavior as Dispose()
- it's just that sometimes 'Close' is a more natural name to use.

--
mikeb
Nov 18 '05 #10

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
Anyone have appropriate experience which would allow them to easily
test this? While I have SQL Server on my laptop, I'm not convinced I
would know how to really *reliably* test this. I'll have a go though :)


I've had a go, and it seems to be false. Here's my test code:

using System;
using System.Data;
using System.Data.SqlClient;
using System.Threading;

class Test
{
static void Main()
{
OpenAndCloseConnection();
OpenAndCloseConnection();
OpenAndCloseConnection();
Console.WriteLine ("Finished opening and closing");
Console.ReadLine();
OpenAndDisposeConnection();
OpenAndDisposeConnection();
OpenAndDisposeConnection();
Console.WriteLine ("Finished opening and disposing");
Console.ReadLine();
}

static void OpenAndCloseConnection()
{
SqlConnection conn = new SqlConnection
("Server=treebeard;Integrated Security=SSPI;Database=Northwind");

conn.Open();
SqlCommand cmd = new SqlCommand
("SELECT COUNT(*) FROM REGION");
cmd.Connection = conn;
cmd.ExecuteNonQuery();
conn.Close();
}

static void OpenAndDisposeConnection()
{
SqlConnection conn = new SqlConnection
("Server=treebeard;Integrated Security=SSPI;Database=Northwind");

conn.Open();
SqlCommand cmd = new SqlCommand
("SELECT COUNT(*) FROM REGION");
cmd.Connection = conn;
cmd.ExecuteNonQuery();
conn.Dispose();
}
}

And here's what I saw in my profiler:

Audit Login
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
Audit Login
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
Audit Logout
Audit Logout

The SPID was 51 except for one Login and one Logout where it was 53 - I
assume that was another connection being started in case it was needed,
although I wouldn't like to say for sure.

Anyway, I can't see any difference from the above between calling
Dispose and calling Close. Have I done something wrong, or is the idea
that Dispose removes the connection from the pool just an urban myth?


I'm sure it is a myth. First, just like you say, MS encourages developers to
use the 'using' statement with the connection which ends up calling Dispose.
I don't think MS would encourage this practice if it indeed removed the
connection from the pool as this would be a costly operation. Second, if you
take a look at what SqlConnection.Dispose does with your favorite
decompiler, you'll see that Dispose does almost nothing but calls Close.
Therefore, Dispose does the same thing as Close does, which is to put the
connection *back* to the connection pool if pooling is on. If pooling is not
on, it closes the physical connection.

Sami
Nov 18 '05 #11
Hi,

After executing the sample example in 'Jon Skeet' post and examining the
sqlprofiler
i have to agree with him, its a urban Myth..

The following statement is wrong.
The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise to call Dispose() unless you want connection to be removed from the
connection pool.
Thanks Jon for correcting me.

Regards
Ashish M Bhonkiya
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Ashish M Bhonkiya <bh******@hotmail.com.nospam> wrote:
You are correct.

The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practise to call Dispose() unless you want connection to be removed from the
connection pool.


Any evidence for this? I've heard talk of it before, but thought that
someone had disproved it in the same thread. It would certainly seem an
odd decision to make, as in languages such as C# with its "using"
statement, Dispose() is the most natural method to call.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 18 '05 #12
Hi Bob,

Have a look at this thread wherefore I have the url below (and only needed
are some answers from Angel, those declares in my opinion everything)

This end statement from him in one message was for me the most clear
The code for Dispose does two things:
1) sets the connection string to ""
2) calls close.
There is no difference between calling either close or dispose (or
both), but you have to make sure to call them during a "finally" to
ensure that you close the connection even when there is an exception.
We added IDisposable support for ado.net classes just so that we could
use the "using" clr construct which is the most visually pleasing way
to write this type of code. In VB.NET you have to make sure to use try
finally blocks.

An advice from him in this thread as well which I found important is to use
dispose for application which have more than 100 connections.

http://tinyurl.com/yrzh4

I hope this helps?

Cor
Nov 18 '05 #13
Does anyone know if the Dispose() method supresses the call to Finalize() if
Dispose has been called (for the SqlConnection object)?

Mythran
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:e3**************@TK2MSFTNGP10.phx.gbl...
Hi Bob,

Have a look at this thread wherefore I have the url below (and only needed
are some answers from Angel, those declares in my opinion everything)

This end statement from him in one message was for me the most clear
The code for Dispose does two things:
1) sets the connection string to ""
2) calls close.
There is no difference between calling either close or dispose (or
both), but you have to make sure to call them during a "finally" to
ensure that you close the connection even when there is an exception.
We added IDisposable support for ado.net classes just so that we could
use the "using" clr construct which is the most visually pleasing way
to write this type of code. In VB.NET you have to make sure to use try
finally blocks.

An advice from him in this thread as well which I found important is to use
dispose for application which have more than 100 connections.

http://tinyurl.com/yrzh4

I hope this helps?

Cor

Nov 18 '05 #14
Mythran wrote:
Does anyone know if the Dispose() method supresses the call to Finalize() if
Dispose has been called (for the SqlConnection object)?

GCSuppressFinalize() actually gets called when the connection is
created. Since the connection pool is managing the object lifetime
(regardless of whether it's disposed), the constructor disables the
finalizer right off the bat.

I'm not sure what the implications of this are for non-pooled
connections if you forget to close or dispose them.


"Cor Ligthert" <no**********@planet.nl> wrote in message
news:e3**************@TK2MSFTNGP10.phx.gbl...
Hi Bob,

Have a look at this thread wherefore I have the url below (and only needed
are some answers from Angel, those declares in my opinion everything)

This end statement from him in one message was for me the most clear
The code for Dispose does two things:
1) sets the connection string to ""
2) calls close.
There is no difference between calling either close or dispose (or
both), but you have to make sure to call them during a "finally" to
ensure that you close the connection even when there is an exception.
We added IDisposable support for ado.net classes just so that we could
use the "using" clr construct which is the most visually pleasing way
to write this type of code. In VB.NET you have to make sure to use try
finally blocks.

An advice from him in this thread as well which I found important is to use
dispose for application which have more than 100 connections.

http://tinyurl.com/yrzh4

I hope this helps?

Cor


--
mikeb
Nov 18 '05 #15
There is a common misconception going around regarding SqlConnection close
and dispose being different, this is not true.

Dispose does only two things, first it clears the SqlConnection connection
string, then it calls Close.

Calling Close or Dispose on a finally block or using the SqlConnection
inside a "using" statement is highly recommended, this will avoid very
common problems with leaking connections when an exception happens on
execute.

Hope this helps,
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
"Mythran" <ki********@hotmail.com> wrote in message
news:e4**************@TK2MSFTNGP11.phx.gbl...

"Bob Lehmann" <none> wrote in message
news:OK**************@TK2MSFTNGP10.phx.gbl...
Hi,

My understanding is that Dispose() should not be used for destroying a
connection object, and that Close() is preferred.

However, in one of MS's Quickstart Apps I see this being used....

This is found in the SqlHelper class -

Dim cn As New SqlConnection(connectionString)
Try
cn.Open()
'call the overload that takes a connection in place of the connection
string
Return ExecuteScalar(cn, commandType, commandText, commandParameters)
Finally
cn.Dispose()
End Try

Is this the correct way to do this?

Bob Lehmann

This is done because the Open method is inside the Try block and in the

Finally block you have no idea whether or not the connection opened successfully. What if the connection opened but there's a bug in the connection itself? If you call close you may get an error, or any other method may throw an exception.

Dispose makes sure the connection is properly closed prior to the object being destroyed. This is a proper technique used to ensure that whether or not the connection was opened, it will be closed before the end of the Try...Finally block has been closed.

Make sense?

Mythran

Nov 18 '05 #16
The following information is not true for SqlClient:

<Warning, not true>
"The Dispose() method releases all resources associated to the connection
object (including removing it from the connection pool). Not a good practice to call Dispose() unless you want connection to be removed from the
connection pool." </Warning>

It is very simple to write an application that disproves this so if you have
any questions you should try it yourself. Dispose only does two things,
first it deletes the connection string and then it calls Close. There is no
functional difference between Close and Dispose and you can call either or
both without a problem.

It is highly recommended that you call Close inside of a Finally block or
that you use the "using" construct when using SqlConnections to make sure
that the connections are properly closed and that you don't leak connections
in cases where execute throws an exception.
Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
"Bob Lehmann" <none> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl... OK - got it.

Thanks,
Bob Lehmann

"Mythran" <ki********@hotmail.com> wrote in message
news:#2**************@TK2MSFTNGP12.phx.gbl...

"Bob Lehmann" <none> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl...
Thanks, Jon.

So, is there any reason to *ever* use Close() instead?

Bob Lehmann
Yes, quoted from Ashish:

"The Dispose() method releases all resources associated to the connection object (including removing it from the connection pool). Not a good

practise
to call Dispose() unless you want connection to be removed from the
connection pool."
That about sums it up :)

If you are worried about connection pooling, you will want to not use
Try...Finally and Dispose(). You will use Try...Finally and then check

to see if
1.) the connection exists 2.) it's open 3.) call Close().

Hope this helps :)

Mythran


Nov 18 '05 #17
Kudos on trying it for yourself! Yes you are completely correct, Close and
Dispose are functionally exchangeable and when using Pooling Dispose will
certainly not remove the connection from the pool.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
"Sami Vaaraniemi" <sa**********@pleasejippii.fi> wrote in message
news:c8**********@phys-news1.kolumbus.fi...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...
Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
Anyone have appropriate experience which would allow them to easily
test this? While I have SQL Server on my laptop, I'm not convinced I
would know how to really *reliably* test this. I'll have a go though
:)
I've had a go, and it seems to be false. Here's my test code:

using System;
using System.Data;
using System.Data.SqlClient;
using System.Threading;

class Test
{
static void Main()
{
OpenAndCloseConnection();
OpenAndCloseConnection();
OpenAndCloseConnection();
Console.WriteLine ("Finished opening and closing");
Console.ReadLine();
OpenAndDisposeConnection();
OpenAndDisposeConnection();
OpenAndDisposeConnection();
Console.WriteLine ("Finished opening and disposing");
Console.ReadLine();
}

static void OpenAndCloseConnection()
{
SqlConnection conn = new SqlConnection
("Server=treebeard;Integrated Security=SSPI;Database=Northwind");

conn.Open();
SqlCommand cmd = new SqlCommand
("SELECT COUNT(*) FROM REGION");
cmd.Connection = conn;
cmd.ExecuteNonQuery();
conn.Close();
}

static void OpenAndDisposeConnection()
{
SqlConnection conn = new SqlConnection
("Server=treebeard;Integrated Security=SSPI;Database=Northwind");

conn.Open();
SqlCommand cmd = new SqlCommand
("SELECT COUNT(*) FROM REGION");
cmd.Connection = conn;
cmd.ExecuteNonQuery();
conn.Dispose();
}
}

And here's what I saw in my profiler:

Audit Login
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
Audit Login
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
RPC:Completed - exec sp_reset_connection
SQL:BatchCompleted - SELECT COUNT(*) FROM REGION
Audit Logout
Audit Logout

The SPID was 51 except for one Login and one Logout where it was 53 - I
assume that was another connection being started in case it was needed,
although I wouldn't like to say for sure.

Anyway, I can't see any difference from the above between calling
Dispose and calling Close. Have I done something wrong, or is the idea
that Dispose removes the connection from the pool just an urban myth?
I'm sure it is a myth. First, just like you say, MS encourages developers

to use the 'using' statement with the connection which ends up calling Dispose. I don't think MS would encourage this practice if it indeed removed the
connection from the pool as this would be a costly operation. Second, if you take a look at what SqlConnection.Dispose does with your favorite
decompiler, you'll see that Dispose does almost nothing but calls Close.
Therefore, Dispose does the same thing as Close does, which is to put the
connection *back* to the connection pool if pooling is on. If pooling is not on, it closes the physical connection.

Sami

Nov 18 '05 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Franco Gustavo | last post by:
Hi I have a Architecture question. (Put the text on courier new font to understand the graphic) Imagine that you have the next objects: A = Form B = Panel C = ButtonEx inherit from Button D...
9
by: Alvin Bruney [MVP] | last post by:
with the using construct, exit from scope calls dispose on said object. But what happens in a connection pooling scenario? Is the run-time smart enough to realize that Object Pooling is being used...
4
by: xyu | last post by:
Hello, First I would like to thank anyone who helps me, much appreciated. I'm a c++ programmer just started using c#. I'm writing some big hash table so I want to actively take my object off...
5
by: Mathias L. | last post by:
I have two questions for which I couldnt find answer: If I programaticaly close DialogForm (calling Close()), is it enough or do I have to dispose it as MS.NET help says? Also, in overriden...
11
by: Michael Rodriguez | last post by:
Suppose I have a dataset, dsMain, that is already filled with data. What then, is the affect of this: DataSet ds1 = dsMain; Does this cause ds1 to simply become a pointer to dsMain? If so,...
9
by: Hasani \(remove nospam from address\) | last post by:
I was reading a ppt ( http://www.gotdotnet.com/team/pdc/4064/tls310.ppt ) and came aross this statement. "Users can leverage a destructor. The C++ compiler generates all the Dispose code...
21
by: Roland | last post by:
The following issue is puzzling me: There are 2 ways of writing the code below: .... Dim fnt as Font = New Font(...) DrawString(myText, fnt,...) fnt.dispose(). or DrawString(myText, New...
4
by: phl | last post by:
hi, My question is: 1. To avoid possible memory leaks, when you use this pattern, after you have dealth with the unmanaged resources and before you take your object off the finalize queue,...
10
by: mg | last post by:
I'm migrating from VB6 and have a question about using 'Using' and the best way to use it. Here is a example of a small bit of code: dbConx("open") Using CN Dim CMD As New OleDbCommand(sSQL,...
7
by: heddy | last post by:
I have an array of objects. When I use Array.Resize<T>(ref Object,int Newsize); and the newsize is smaller then what the array was previously, are the resources allocated to the objects that are...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.