Should I call Dispose on a SQLCommand object?

Should I call Dispose on a SQLCommand object If I do, what exactly gests disposed

Jonathan


Answer this question

Should I call Dispose on a SQLCommand object?

  • Softpen

    Luke,

    That's correct. The using construct actually calls Dispose, for example the above code is actually getting converted underneath to the following code by the C# compiler:



    SqlCommand command = new SqlCommand();
    try
    {
    // Do Something with the command
    }
    finally
    {
    if (command != null)
    {
    command.Dispose();
    }
    }

    As you can see even if something in the try block throws an exception, the command will always be disposed. Whereas, if you only just call Dispose (and not use 'using' or the above try...finally, anything that throws an exception will prevent the object from being disposed.

    And yes, calling SqlConnection.Dispose (or using wrapping it in a 'using' construct) also closes the connection.



  • Sahil Jain

    Exactly what resources get released when I call dispose on a SQLCommand

    Jonathan

  • manik

    The article Paul references is a great resource on Dispose and Finalize.

    The basic rule is that if an object you create implements Dispose, then you should allways call it to ensure the timely release of resources.

    Dispose cleans up any managed and unmanaged resources the object might have created, and ensures the early release of resources back to the system.

    Calling Dispose on an object doesnt do anything special to it with regard to the GC.  Dispose is only there to allow the object to release resources it was holding onto.  If you still hold references to the object it wont be collected untill all the references are removed.

    Regards

    Steve

  • Anand S N

    Hi,

    Disposing an object is just like marking an object for disposal when the Garbage collector runs. So that it would be removed from the memory. Well, if you don't need your object then you must indeed call a dispose against it...




    cheers,

    Paul June A. Domag


  • Chinh Nguyen

    Hi,

    Thanks for clearing that up David. Big Smile



    cheers,

    Paul June A. Domag


  • wayne-o

    I'd like to clear something up -- is it considered good practice to use the using construct and not call the Dispose method Taking this one step further, if the object is a SqlConnection, will the using statement close and dispose it If so, it would seem that the using construct would be a best practice in many places

    I'm obsessed with best practices .

  • Neax

    Hi,

    Yes after calling dispose to an object it still could hold references. This is because the GC runs non-deterministically. But once the GC runs it removes all disposed objects in the managed heap. In a .Net scenario you cannot explicitly remove an object from the memory unlike in C++ in which you can explicitly delete an object. Once an object implements IDisposable or provides a Dispose() mechanism, it should always be called if you deem not to use the object anymore to avoid resource/memory leaks. Here is an article that discusses this. It might be of help to you.  Dispose, Finalization and Resource Management.



    cheers,

    Paul June A. Domag


  • Steve Billingsley

     Jonathan Allen wrote:
    Exactly what resources get released when I call dispose on a SQLCommand

    Jonathan


    Well actually not a lot. However, SqlCommand indirectly inherits from Component which implements a finalizer. A finalizer is a special method that is called by the Garbage Collector (GC) to clean up unmanaged resources, in constrast, the Dispose method defined by the IDisposable interface (which the GC knows nothing about) cleans up both managed and unmanaged resources. Objects that implement finalizers are specially handled by the GC and are not removed from memory the first time the GC encounters an out-scope one. Rather its finalizer is first called, and then only the next time the GC encounters it, is it removed from memory. This makes objects with finalizers expensive to clean up and therefore you only want them to run in extreme circumstances.

    To prevent a finalizer from running, most well written Dispose implementations call a special method called GC.SuppressFinalize, which indicates to the GC that its finalizer shouldn't be run when it falls out of scope (as the Dispose method did the clean up). The component class (which remember the SqlCommand indirectly inherits from), implements such a Dispose method. Therefore to prevent the finalizer from running (and even though it does nothing in the case of SqlCommand), you should always call Dispose.

    The easiest way to ensure that a IDisposable implementor has its Dispose method called, is to wrap it in the using construct:

    C# 2002, 2003 and 2005:


    using (SqlCommand command = new SqlCommand())
    {
          // Do Something with the command

    }

     


    VB 2005 Only:


    Using command As New SqlCommand()

       ' Do something with the command

    End Using

     


    The using construct guarantees that the Dispose method of an IDisposable implementor will be called, even in the case of an exception.

    Paul: Just to make it clear: the GC knows nothing about Disposable objects. When it runs, the only objects that it will remove (or look at removing*) are objects that have fallen out of scope. So calling Dispose on an object does not indicate to the GC that the object's memory needs to be freed.

    * The Garbage Collector can still decide whether or not to free an object that is out of scope based on its lifetime, memory pressure and other internal factors only known to it.

    If you want to read up more about the Garbage Collector, I recommend you read Applied .NET Framework Programming by Jeffrey Richter, an awesome book that should be on the must read of all .NET developers.


    Hope that makes it a little clearer

    David

  • local

    No, it doesn't mark an object for disposal. In fact, there is nothing that can do that to an object. I can call dispose and it still hold on a reference to it as long as I want.

    The Dispose method may, but doesn't have to, tell the GC that the Finalizer doesn't need to be run. However, that is implementation specific, hence my question.

  • Should I call Dispose on a SQLCommand object?