I know I asked a related question earlier. I just had another thought.
using (SqlConnection conn = new SqlConnection('blah blah'))
{
using(SqlCommand cmd = new SqlCommand(sqlStatement, conn))
{
conn.open();
// *** do I need to put this in using as well? ***
SqlDataReader dr = cmd.ExecuteReader()
{
While(dr.Read())
{
//read here
}
}
}
}
The argument is that: Since the SqlDataReader dr object is NOT A NEW OBJECT LIKE THE connection or command objects, its simply a reference pointing to the cmd.ExecuteReader() method, do I need to put the reader inside a using. (Now based on my previous post, it is my understanding that any object that uses IDisposable needs to be put in a using, and SQLDataReader inherits from IDisposable, so I need to put it. Am I correct in my judgement?) I am just confused since its not a new object, would it cause any problems in disposing an object that simply is a reference pointer to the command?
Many thanks
I think you are mistaken. The
dris a reference to the object returned bycmd.ExecuteReader, which is going to be a new object. In your example, nothing will disposedr, so yes it needs to be in ausing, or manually disposed.Your judgement about
IDisposableimplementors needing to be in ausingis not correct. They will function fine outside. Ausingstatement is just syntactic sugar for atry ... finally. Things implementingIDisposableshould haveDisposecalled, because they are signalling that they need to dispose certain state in a deterministic way.Note that if you do not call
Dispose, its not always a problem. Some objects also implement the finalizer, which will be triggered by the garbage collector. If they do not implement the finalizer, they might leave unmanaged memory unreclaimed. This will remain unreclaimed until your application closes. All managed memory is eventually reclaimed, unless it is not elligible for garbage collection.Re-written: