Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is it better to reuse SqlCommand when executing the same SQL query several times?

When querying the database with the same query but different parameters, is it better to:

  • do it in a single using,
  • or to create two separate queries?

Example of a single using:

using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection))
{
    // Insert the first product.
    addProduct.Parameters.AddWithValue("@name", "Product 1");
    addProduct.Parameters.AddWithValue("@price", 41F);
    int countAffectedRows = addProduct.ExecuteNonQuery();
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected.");

    addProduct.Parameters.Clear();

    // Insert the second product.
    addProduct.Parameters.AddWithValue("@name", "Product 2");
    addProduct.Parameters.AddWithValue("@price", 49.9);
    countAffectedRows = addProduct.ExecuteNonQuery();
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected.");
}

Example of the same code using two separate queries:

// Insert the first product.
using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection))
{
    addProduct.Parameters.AddWithValue("@name", "Product 1");
    addProduct.Parameters.AddWithValue("@price", 41F);
    int countAffectedRows = addProduct.ExecuteNonQuery();
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected.");
}

// Insert the second product.
using (SqlCommand addProduct = new SqlCommand(@"insert into [Products].[Products] ([Name], [Price]) values (@name, @price)", sqlConnection))
{
    addProduct.Parameters.AddWithValue("@name", "Product 2");
    addProduct.Parameters.AddWithValue("@price", 49.9);
    int countAffectedRows = addProduct.ExecuteNonQuery();
    Debug.Assert(countAffectedRows == 1, "Wrong number of rows affected.");
}

In my opinion, the second one must be preferred, because:

  • it makes it more clear to see where the SQL command is disposed and how much times it is executed,
  • it is easier to modify if, in future, for some reason, the query must be modified in one case, but not in the other,
  • the first one makes it easy to forget the SqlCommand.Parameters.Clear().

On the other hand, the first sample is more explicit about the fact that the query is the same in both cases, and that only parameters change.

like image 537
Arseni Mourzenko Avatar asked Jan 06 '11 23:01

Arseni Mourzenko


People also ask

Can you reuse Sqlcommand object?

Unlike reusing an instance where the text and parameters are kept the same, reusing an instance to clear everything before making it a "new" command has much less practical application (as opposed to actually creating a new command).

What is Sqlcommand?

SQL stands for Structured Query Language. SQL commands are the instructions used to communicate with a database to perform tasks, functions, and queries with data. SQL commands can be used to search the database and to do other functions like creating tables, adding data to tables, modifying data, and dropping tables.


1 Answers

There's very little benefit to reusing the command instance, unless you're planning to call Prepare.

If you're going to run the command many times (dozens or more), then you probably want to create the command, prepare it, execute it in a loop, and then dispose it. The performance gains are significant if you're running the command many times. (You would add the parameters once, though, before you prepare -- not delete and re-add them every time like you're doing in your first code sample. You should change the parameters' values each time, not create new parameters.)

If you're only going to be running the command a handful of times, performance isn't an issue, and you should go with whichever style you prefer. Creating the command each time has the benefit that it's easy to extract into a method so you don't repeat yourself.

like image 64
Joe White Avatar answered Sep 17 '22 09:09

Joe White