Do I have to Dispose the SQLiteCommand objects?

问题:

How do I treat the SQLiteCommand object, do I have to call Dispose() after ExecuteScalar, ExecuteNonQuery and ExecuteReader or not?

The documentation example on SQLiteCommand doesn't dispose it whilst in the SQLiteTransaction the example disposes the SQLiteCommand object.

I always close the data reader object though. My application accesses the db from many threads.

Mostly I am interested in not leaking connections or disturbing SQLite. I am aware of using and IDisposable usage

回答1:

It's best-practise to dispose everything that implements IDisposable as soon as you're finished with it because it might use unmanaged resources.

This should be done with the using-statement since it wraps the code that uses this object and because it disposes it also in case of an exception.

using(var con = new SQLiteConnection(conString))
using(var cmd = new SQLiteCommand(con))
{
    con.Open();
    // ...
} // also closes the connection

回答2:

If it is disposable, dispose it if you will not use it again. The best would be, to use using

using(SQLiteCommand cmd as new SQLiteCoammand())
{
   ...
}

So it will be disposed automatically when leaving the using scope.

回答3:

Just do this:

using(var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConn"].ConnectionString))
using(var command = connection.CreateCommand())
{
   command.CommandText = "...";
   connection.Open();
   command.ExecuteNonQuery();
}

Not calling dispose on the command won't do anything too bad. However calling Dispose on it will supress the call to the finalizer, making calling dispose a performance enhancement.

回答4:

The using statement will call Dispose on an object even if an exception occurs that bypasses the code that calls Close(). This way you don't have to write a try/finally block just to close the readers or the connection. You also avoid this 1-in-100 case where you forget to write the proper finally block.

Such 1-in-100 cases have a tendency to occur much more frequently than one would think