Можно ли как-нибудь вызвать системное исключение при перехвате исключения вручную? - PullRequest
Новая
       17

Можно ли как-нибудь вызвать системное исключение при перехвате исключения вручную?

1 голос
/ 16 марта 2010

Я пишу хранимую процедуру, в которой я использую блок try catch.

Теперь у меня есть уникальный столбец в таблице. Когда я пытаюсь вставить повторяющееся значение, оно выдает исключение за исключением 2627.

Я хочу, чтобы это было сделано так

if (существует (выберите * из tblABC, где col1 = 'value') = true) riseError (2627) - вызвать системную ошибку, которая возникла бы, если бы я использовал запрос вставки для вставки дублирующегося значения

EDIT:

Я использую транзакцию, которая получает откат при обработке исключения, что приводит к увеличению значения @@ Identity, которое было выполнено в предыдущих запросах b4 Возникла исключительная ситуация.

Я хочу проверить все такие исключения, которые могут возникнуть при вставке b4. Для этого я проверю исключение, которое может вызвать ошибку вручную, используя оператор select с if else. Здесь я смогу отследить нарушение уникального ключа, но исключение не произойдет, поэтому я буду генерировать исключение намеренно, но это исключение, которое я хочу, должно быть системным исключением, т.е. ошибка 2627

И какой метод будет лучше, используя вставить запрос или проверка на дубликат значение перед вставкой с помощью Select запрос?

ВОЗМОЖНО ЛИ КАК ПОДНЯТЬ СИСТЕМУ ИСКЛЮЧЕНИЕ ПО ЛОСКУ ИСКЛЮЧЕНИЕ ВРУЧНУЮ, т. Е. Бросая то же самое исключение, что SQL вылетел бы

1 Ответ

2 голосов
/ 16 марта 2010

Вы не можете вызвать системные ошибки. RAISERROR (2627 ...) является незаконным. Помимо того, что вы лжете (ошибка 2627 не произошла), вам не хватает вставок в формат сообщения.

Приложение никогда не должно полагаться на непрерывность IDENTITY, тот факт, что вы жалуетесь на то, что это «увеличивает автоинкремент», приводит к тому, что ваше приложение имеет ошибку (в дизайне, если не в коде). Значения IDENTITY могут содержать пробелы, являющиеся частью их спецификаций.

Что лучше, вставлять и ловить, либо пытаться обновить: это зависит от вашего распространенного паттерна. Если значение, вероятно, существует, первая стратегия ОБНОВЛЕНИЯ лучше. Если значение, вероятно, не существует или если вероятность неизвестна , лучше ВСТАВИТЬ и отловить ошибку по соображениям производительности и, что более важно, правильности (проверка SELECT никогда не бывает корректной при параллельности).

...