dispose is not a good idea. Close is enough. This releases the Connection
back to the pool. When you reopen the connection the (existing) object can
re-address a valid pooled connection.
> This is the point. The fact of a connection object be marked as "disposed"
> to the GC will afect the app performance, if after this dispose I make
> another connection, with another object, to the same database? Dispose a
> connection object will afect the way as ADO.net uses data in "cache" to
> other connections?
> My doubt is: whats the better choice to close connections in an
> wich open and closes connections to a database many times? Just call
> or Dispose, too?
> > The documentation is incorrect. Dispose does not remove a connection
> > the pool. Calling dispose (as Scott said) closes the connection and
> > the object for disposal when the garbage collector runs.
> > --
> > ____________________________________
> > Bill Vaughn
> > www.betav.com
> > Please reply only to the newsgroup so that others can benefit.
> > This posting is provided "AS IS" with no warranties, and confers no
> > __________________________________
> > > Hi Scott,
> > > I have another doubt concerning the data access: if I'll open and
> > the
> > > connections each time I need, is it a good idea to call the Dispose
> > > of the connections, or it will compromise this ADO.NET pooling?
> > > Thanks again,
> > > Fabrcio.
> > > > That won't be enough if there is concurrent access, and it sounds
> > > > there is.
> > > > The easiest solution is to create a new connection each time a
> > > > makes a call to your object, and close the connection as soon as
> > > > possible. Don't worry about the overhead of setting up and tearing
> > > > down real database connections as ADO.NET will pool the connections
> > > > for you, assuming you are using the same connection string and
> > > > security context each time.
> > > > If you really want to restrict yourself to a single connection,
> > > > need to serialize calls (look up the Monitor class, or the lock
> > > > keyword in C#) while the data readers are open. This limits the
> > > > throughput of your object however, so I'd suggest the earlier
> > > > solution.
> > > > On Wed, 28 May 2003 00:49:18 -0700, "Terminator"
> > > > >You should close the datareader once done fetching the data before
> > using
> > > the
> > > > >next data reader. An open data reader locks the connection.
> > message
> > > > >> Hi all,
> > > > >> My app has an object published on the server, wich is accessed by
> > > > >> clients in Singleton mode. This object uses an unique and static
> > > > >> OleDbConnection.
> > > > >> In some methods, I use DataReaders (one by time), attacheds to
> > > > >> connection. When I'm running the app, I get errors concerning the
> > > > >> DataReaders; the compiler shows errors telling me that the
> > > > >can't
> > > > >> have more than one Datareader attached.
> > > > >> I think this error occurs because The OleDb object is a static
> > object,
> > > and
> > > > >> more than one client tries to create datareaders.
> > > > >> Is my supposition correct? If no, what can be the problem?
> > > > >> If yes, whats the best way to correct? Changing to SingleCall?
> > a
> > > > >> dynamic OleDbConnection?
> > > > >> Thanks in advance,
> > > > >> Fabrcio de Novaes Kucinskis.
> > > > --
> > > > Scott