Introduction

With ADO.NET resource handling, developers often ask whether SqlCommand.Close() or Dispose() should be called. The short answer is that SqlCommand is normally disposed, while Close() is more relevant to readers and connections. Understanding which object actually owns the expensive resource avoids redundant cleanup code and makes data-access code safer.

What SqlCommand Actually Owns

SqlCommand represents the SQL text, parameters, and execution context for a database operation. It cooperates with a SqlConnection, and sometimes with a SqlDataReader, but it is not the network connection itself.

Typical usage:

1using System.Data.SqlClient;
2
3using var connection = new SqlConnection(connectionString);
4using var command = new SqlCommand(
5    "SELECT COUNT(*) FROM dbo.Users WHERE IsActive = 1",
6    connection
7);
8
9connection.Open();
10var count = (int)command.ExecuteScalar();
11Console.WriteLine(count);

In this flow, the important lifetime boundary is usually the connection, not the command.

Close() Versus Dispose()

For SqlCommand, Dispose() is the meaningful cleanup method. Close() is not the method you usually think about for commands. In day-to-day ADO.NET work:

• call Dispose() on SqlCommand, usually via using
• call Close() or Dispose() on SqlConnection if not using using
• call Close() or Dispose() on SqlDataReader when finished reading

The reason this feels confusing is that many examples mix up cleanup responsibilities across related objects.

Best Practice: Use using

The cleanest pattern is scoped disposal.

1using System.Data.SqlClient;
2
3using var connection = new SqlConnection(connectionString);
4using var command = new SqlCommand(
5    "UPDATE dbo.Tasks SET Processed = 1 WHERE Id = @id",
6    connection
7);
8
9command.Parameters.AddWithValue("@id", 42);
10
11connection.Open();
12var rows = command.ExecuteNonQuery();
13Console.WriteLine(rows);

This ensures Dispose() is called automatically even if an exception occurs. It also removes the need to remember separate manual cleanup calls.

Reader Ownership Is More Important Than Command Close

When a command returns a SqlDataReader, the reader can keep the connection busy until it is closed or disposed.

1using System.Data.SqlClient;
2
3using var connection = new SqlConnection(connectionString);
4using var command = new SqlCommand(
5    "SELECT Id, Email FROM dbo.Users",
6    connection
7);
8
9connection.Open();
10using var reader = command.ExecuteReader();
11
12while (reader.Read())
13{
14    Console.WriteLine($"{reader.GetInt32(0)} {reader.GetString(1)}");
15}

In this example, failing to dispose reader is usually a bigger problem than worrying about command.Close().

Manual Cleanup When using Is Not Possible

If you must manage lifetimes manually, dispose in reverse order of usage.

1SqlConnection? connection = null;
2SqlCommand? command = null;
3
4try
5{
6    connection = new SqlConnection(connectionString);
7    command = new SqlCommand("SELECT 1", connection);
8    connection.Open();
9
10    Console.WriteLine(command.ExecuteScalar());
11}
12finally
13{
14    command?.Dispose();
15    connection?.Dispose();
16}

This is still valid, but more error-prone than scoped disposal.

Why Redundant Close() Calls Usually Add No Value

Some code bases call both Close() and Dispose() on every object. That is usually noise, not safety. Dispose() already represents final cleanup for disposable objects. Repeating both calls makes intent less clear and encourages copy-paste patterns rather than ownership-based reasoning.

If you see both everywhere, simplify where possible and let using express lifetime clearly.

CommandBehavior.CloseConnection

One special case is reader-driven connection cleanup.

1using var connection = new SqlConnection(connectionString);
2using var command = new SqlCommand("SELECT Name FROM dbo.Products", connection);
3
4connection.Open();
5using var reader = command.ExecuteReader(CommandBehavior.CloseConnection);
6
7while (reader.Read())
8{
9    Console.WriteLine(reader.GetString(0));
10}

Here, closing the reader also closes the connection. This can be useful, but it should be used intentionally because it couples reader lifetime to connection lifetime.

Common Pitfalls

• Calling Close() on SqlCommand out of habit while ignoring reader or connection disposal.
• Manually cleaning up every object instead of using using.
• Forgetting that an open SqlDataReader can hold the connection busy.
• Assuming garbage collection will promptly release database-related resources.
• Writing redundant Close() plus Dispose() sequences that obscure real ownership.

Summary

• For SqlCommand, Dispose() is the cleanup action that matters most.
• 'Close() is more relevant to connections and readers than to commands.'
• Prefer using so disposal happens automatically and safely.
• Focus resource management on the objects that actually hold expensive state.
• Keep cleanup code simple, explicit, and based on ownership rather than habit.