Спасибо за ваш ввод OMG / Martin, но оказывается, что корень моей проблемы был из-за значения параметра, равного нулю.
В частности:
--sproc params
@f1 int,
@f2 nvarchar(30),
@f3 datetime = null --<<a null value will screw up the IF() condition
IF(SELECT COUNT(f1)
FROM table
WHERE f1 = @f1
AND f2 = @f2
AND f3 = @f3)
<1
BEGIN
INSERT INTO....
END
Обратите внимание, что значение по умолчанию для параметра @ f3 равно нулю. Таким образом, в случае, когда вызывающая сторона sproc не передает параметр @ f3, условие IF () вернет 0 (ноль), даже если есть совпадающие @ f1, @ f2 и null @ f3.
Например: скажем, в таблице уже есть запись
f1 f2 f3
--------------
45 foo NULL
Теперь вызывающая сторона запускает спрока, отправляя его:
@ f1 = 45
@ f2 = Foo
(обратите внимание, что вызывающая сторона не указывает @ f3)
Если условие IF (), если оно выполнено, оно вернет 0 (ноль). Странно, а? Интуитивно я думаю, что условие вернет 1, поскольку параметры точно соответствуют существующим значениям в таблице.
Чтобы немного усложнить ситуацию (во всяком случае, для меня), это то, что хотя IF () завершается успешно (возвращает ноль), я получаю исключение "Нарушение ограничения UNIQUE KEY ..". На самом деле, я не удивлен, что возникает исключение, так как я считаю, что значения параметров идеально соответствуют существующей записи в таблице - для меня запутанная часть, почему условие IF () противоречит исключению нарушения .
Кстати, OMGPonies, я пытался использовать ваше предложение (EXISTS), и появляются те же симптомы. По-видимому, NULL-фактор усложняет ситуацию.