Уточню ответ Павла. SQL Server допускает использование рекусривных триггеров (простых). По умолчанию она отключена. Для включения нужно установить опцию Nested Triggers базы данных.
Даже с отключенной опцией Nested Triggers при выдачи команды Update изнутри триггера на Insert при выдачи команды Insert действительно запустятся оба триггера. Такая ситуация не считается рекурсивным запуском триггеров. Рекурсивным считается триггер, который приводит к запуску самого себя.
Если тебе нужно не допустить запуск триггера, если операция запущена из другого триггера, то выходов несколько.
1. Перейти на версию 2000 и использовать Instead-триггеры, которые как раз для таких ситуаций и предназначены (самое лучшее решение).
2. Если заведомо известен перечень всех источников подачи команды Update, и @@NestLevel при запуске триггера на Update при подачи команд от разных источников всегда разный, то можно в самом триггере предусмотреть ветвление по условию проверки переменной @@NestLevel.
3. Самый неизящный метод. Использовать вспомогательную таблицу, в которую помещается @@SPID (для того, чтобы разные сеансы друг другу не мешали) на время работы одного из триггеров. При выходе из триггера - удаляется. Внутри друго триггера можно проверить наличие соответствующей записи во вспомогательной таблице и определить, запущен данный триггер из первого триггера или из другого места.

Успехов

>if (select count(*) from deleted)=0
А вот такие конструкции использовать не рекомендуется! Для подобных проверок существует функция exists(), которая возвращает логический результат сразу, обнаружив только первую запись, не проходя по всем тысячам записям, которые могут оказаться в Deleted (или в другой таблице). Я бы эту фразу написал так:
if not exists(select * from deleted)
А для полноты картины - и звездочку ставить крайне не рекомендуется. Если в select указано только одно ключевое поле - работает еще быстрее.