Я не согласен. В статье описывается, что при максимально точном определении параметра вероятнее использовать план с кэшируемым запросом, который будет использоваться, а затем с более высокой производительностью. Подраздел «Простая параметризация» гласит: «В SQL Server использование параметров или маркеров параметров в операторах Transact-SQL повышает способность реляционного механизма сопоставлять новые операторы SQL с существующими, предварительно скомпилированными планами выполнения.

м связан вопрос:

Какой лучший способ передачи параметров в SQLCommand?

Но я хочу знать, в чем различия и есть ли проблемы с разными способами.

Я обычно использую структуру примерно так:

using (SqlConnection conn = new SqlConnection(connectionString))
using (SqlCommand cmd = new SqlCommand(SQL, conn))
{
     cmd.CommandType = CommandType.Text;
     cmd.CommandTimeout = Settings.Default.reportTimeout;
     cmd.Parameters.Add("type", SqlDbType.VarChar, 4).Value = type;

     cmd.Connection.Open();

     using (SqlDataAdapter adapter = new SqlDataAdapter(cmd))
     {
         adapter.Fill(ds);
     }
      //use data                    
}

Теперь есть несколько способов добавить параметры cmd, и мне интересно, что лучше:

cmd.Parameters.Add("@Name", SqlDbType.VarChar, 20).Value = "Bob";
cmd.Parameters.Add("@Name", SqlDbType.VarChar).Value = "Bob";
cmd.Parameters.Add("@Name").Value = "Bob";
cmd.Parameters.AddWithValue("@Name", "Bob");

Я предполагаю, что иметь длину поля при прохождении varchars не желательно, поскольку это магическое значение, которое может быть изменено позже в базе данных. Это верно? Вызывает ли это какую-либо проблему, передающую varchar таким образом (производительность или другое), я предполагаю, что по умолчанию это varchar (max) или эквивалент базы данных. Я достаточно счастлив, что это сработает.

Больше всего меня беспокоит потеря перечисления SqlDbType, если я использую третий или четвертый варианты, перечисленные выше, я вообще не предоставляю тип. Есть ли случаи, когда это не сработает? Я могу представить проблемы с неверным приведением varchar к char или наоборот, или, возможно, проблемы с десятичной дробью в деньги ....

С точки зрения базы данных, тип поля, который я бы сказал, будет меняться гораздо реже, чем длина, поэтому стоит ли его сохранять?

Ответы на вопрос(2)

Ваш ответ на вопрос