Параметризация sp_executesql имеет много преимуществ, в том числе
- Благодаря явной параметризации вы даете SQL возможность кэшировать приличные планы запросов для определенных типов
- Параметризация помогает предотвратить такие неприятности, какАтаки SQL-инъекций, но также избавляют от необходимости избегать проблемных символов.
Так что даже если вам удастся «непараметризовать» сгенерированный sp_executesql, если вы выполните встроенный sql, план запроса может быть значительноотличается от параметризованной версии, и вам также нужно будет выполнить экранирование и т. д. (т. е. это не подойдет для тестирования яблок и яблок).
Единственная причина, по которой я могу подумать, почему вы не хотите параметризоватьсяsp_executesql будет для удобства чтения?
Редактировать : Попытка замены будет зависеть от того, какую технологию вы используете
Как предложено @mellamokb, если вы используете ExecuteReaderэто может быть довольно просто
Предполагая ваш кодбыло что-то вроде
string sqlCmd = "SELECT CustomerName
FROM CustomerTable ct WITH(NOLOCK)
WHERE ct.CustomerId <> @CustomerId
AND ct.ItemId <> @ItemId
AND ct.TransactionId = @TransactionId";
cmd.CommandText = sqlCmd;
cmd.CommandType = CommandType.Text;
cmd.Parameters.Add(new SqlParameter("CustomerId", DbType.Int32, myCustomerId));
cmd.Parameters.Add(new SqlParameter("ItemId", DbType.String, myItemId));
..
cmd.ExecuteReader()
Затем вы могли бы добавить код для построения вашего тестового запроса:
string sqlMyTest = sqlCmd.Replace("@CustomerId", myCustomerId.ToString());
sqlMyTest = sqlMyTest.Replace("@ItemId", specialEscapeFunction(myItemId));
.. do something with sqlMyTest
Однако ORM, такой как Linq2SQL или EF, не был бы таким простым
customerTable.Where(c => (c.CustomerId != myCustomerId) && (c.ItemId != myItemId) && (c.TransactionId == myTransactionId))
Возможно, вам поможет такой инструмент, как LinqPad?