Gallemar, оффтопну маленько.
Для снижения вероятности дэдлоков есть простой best practice - при доступе к данным БД крайне желательно соблюдать одинаковый порядок обращения к ресурсам (таблицам).

kdv, хороший, вырожденный пример! На нем и поясню, что имеется в виду.
Допустим, календарь нормализован таким образом, что при добавлении нового задания обновляется как справочник заданий, так и сама таблица календаря. Иными словами имеем "строку данных", разбитую на две таблицы, хранящие разные сущности с отношением один-к-одному. Предположим, что есть две хранимые процедуры, одна из которых сначала обновляет таблицу календаря, а затем таблицу заданий. И есть другая хранимая процедура, которая, по какой-то непонятной нам причине, также производит обновление двух этих таблиц, но в обратном порядке. В результате, мы рискуем получить дэдлок, если пытаемся через эти SP обновить одни и те же строки.
Естественно, что в больших базах данных это может быть обновление не одной, не двух, а доброго десятка таблиц. Так вот при блокировки записей в этих таблицах крайне желательно соблюдать идентичный порядок.

Я очепятался. "что при изменении задании обновляется..."

GallemarТы можешь придерживаться темы? Надоел своим "умными" мыслями.
Не психуй! Надо - намотай, не надо - пропусти.

Симонов ДенисDBConstructor, абсолютно пофиг в какой последовательности внутри ХП ты обновляешь таблицы, потому что ХП делает все обновления в рамках одной транзакции.
Очевидно же, что чтобы словить блокировку, эти две ХП должны выполняться в разных транзакциях. Не думал, что придется это пояснять...

Dimitry SibiryakovНу и логика работы приложения тоже сплошной фейспалм.
Димитрий, ну зачем же так грубо? Человек обратился за помощью, а не за тем, чтобы его отшили в грубой форме.