Re: Wii close connection?



Is it not true that the GC will take care of it eventually? Of course it is,
I never stated that this is a good thing I am just stating that it will
happen.

As for the connection pooling issue, I believe this is beyond what the
poster was asking for.
But yes it is true that the underlying connection is not physically closed,
however the resource
is being released and being made available for reuse by other code within
the AppDomain.
This happens regardless of the managed connection being finalized or
explicitly calling Dispose or Close.

Again I state however:
"You should explicitly close the connection..." ie. call Close or Dispose on
the managed connection object.

Hope this clarifies any confusion my original response might have caused.

--
Chris Taylor
http://dotnetjunkies.com/weblog/chris.taylor


"Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message
news:epAg8UbrFHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
> But, that changes when connection pooling (the default) is used. My point
> was that it is confusing and not really the best answer to say that the GC
> will take care of it.
>
>
> "Chris Taylor" <chris_taylor_za@xxxxxxxxxxx> wrote in message
> news:OHwjnuarFHA.3864@xxxxxxxxxxxxxxxxxxxxxxx
> > Yes, however once the GC process will eventually invoke the finalizer
> > which
> > in turn calls Dispose and therefore the connection will be closed.
> >
> > --
> > Chris Taylor
> > http://dotnetjunkies.com/weblog/chris.taylor
> >
> >
> > "Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message
> > news:#isuiRarFHA.3640@xxxxxxxxxxxxxxxxxxxxxxx
> >> Please note that the Garbage Collection of the connection object in
> >> memory
> >> and the closing of the Connection object (to the data source) are not
the
> >> same thing.
> >>
> >> He should explicitly close the connection when he's done with it and
then
> >> the object can be destroyed based on memory management rules.
> >>
> >> "Chris Taylor" <chris_taylor_za@xxxxxxxxxxx> wrote in message
> >> news:uvr5HOarFHA.3796@xxxxxxxxxxxxxxxxxxxxxxx
> >> > Hi,
> >> >
> >> > No, the connection will linger until such time as the garbage
> >> > collection
> >> > process ie. Finalization etc. takes care of releasing the connection
> >> > object.
> >> > You should explicitly close the connection, preferably by using a
> >> > try/finally block to ensure the connection is closed regardless of
> > errors,
> >> > for C# I like the using statement to assist with this.
> >> >
> >> > public int object MyExecuteNonQuery(string sSql)
> >> > {
> >> > string cnnStr="....";
> >> > int iRV;
> >> > using(SqlConnection cnn = new SqlConnection(cnnStr))
> >> > {
> >> > SqlCommand myCommand = new SqlCommand(sSql, cnn);
> >> > cnn.Open();
> >> > iRV=myCommand.ExecuteNonQuery;
> >> > } // At this point the cnn object will be disposed
> >> > return iRV;
> >> > }
> >> >
> >> > Hope this helps
> >> >
> >> > --
> >> > Chris Taylor
> >> > http://dotnetjunkies.com/weblog/chris.taylor
> >> >
> >> >
> >> > "ad" <flying@xxxxxxxxxxxxxxx> wrote in message
> >> > news:#r1TpGarFHA.304@xxxxxxxxxxxxxxxxxxxxxxx
> >> >> I have a function call MyExecuteNonQuery(see bellow)
> >> >> When I call it with some Sql command like:
> >> >> MyExecuteNonQuery("Delete from myTable);
> >> >> Will it close the conneciton which opened in MyExecuteNonQuery?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >>
>
>>> ------------------------------------------------------------------------
-
> > -
> >> > --
> >> >> public int object MyExecuteNonQuery(string sSql)
> >> >> {
> >> >> string cnnStr="....";
> >> >> SqlConnection cnn = new SqlConnection(cnnStr);
> >> >> SqlCommand myCommand = new SqlCommand(sSql, cnn);
> >> >> cnn.Open();
> >> >> int iRV=myCommand.ExecuteNonQuery;
> >> >> return iRV;
> >> >>
> >> >> }
> >> >> /*
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>


.



Relevant Pages

  • Re: Confused about GC & Disposing: How to get it right?
    ... I think the key to understanding if you need to call dispose is to ... The CLR can determine when a connection object is no ... .NET objects that use unmanaged resources (things that the CLR does not ...
    (microsoft.public.dotnet.framework)
  • Re: ODBC/OLE DB Connection Pool
    ... > connection be kept open for the application as this will serialize all ... threads ONCE they are returned to the pool. ... > Tips for ADO Users ... > The ADO Connection object implicitly uses IDataInitialize. ...
    (microsoft.public.data.ado)
  • Re: ODBC/OLE DB Connection Pool
    ... > connection be kept open for the application as this will serialize all ... threads ONCE they are returned to the pool. ... > Tips for ADO Users ... > The ADO Connection object implicitly uses IDataInitialize. ...
    (microsoft.public.inetserver.asp.db)
  • Re: ODBC/OLE DB Connection Pool
    ... > connection be kept open for the application as this will serialize all ... threads ONCE they are returned to the pool. ... > Tips for ADO Users ... > The ADO Connection object implicitly uses IDataInitialize. ...
    (microsoft.public.data.oledb)
  • Re: Garbage Collection and Visual Studio
    ... Don't create the connection object on ... dispose of it. ... >> then use the Dispose method of that class. ... > the same connection object until the form is unloaded. ...
    (microsoft.public.dotnet.languages.csharp)