условие where Sequence=-1 and AppID=' ' явно не достаточно для логического разделения записей, оттого и дедлок между добавляющими и обновляющим процессом.
Попробуйте в этут таблицу добавить поле со временем добавления записи, а в обновляющем процессе использовать его в условии поиска where Sequence=-1 and AppID=' ' and tran_date between ....
А в обновляющем хранить эти интервалы. Тогда не будет таких явных конфликтов и конкуренции.

чиз, у вас два варианта, либо поняв те идеи, что вам накидали применить их в своей задаче, адаптировав под конкретные ваши условия, либо показывать схему таблицы, что и как обрабатывается, т.е. дать решать задачу нам, вместо вас.
Лучше конечно же самому..

ну тогда привязывайтесь ко времени в обработчике, как я предложил.
Только тут важно, что-бы процесс, который назначает номер Q задания для обработчиков был один. Иначе будет та же конкуренция и дедлоки.
Итого выходит так:
- много писателей, которые пишут события. В событии присутствует время поступения. Вот последнее время поступления еще постоянно отражается в вспомогательной табличке.
- Один процесс, который назначает номера на обработку читает из вспомогательных таблиц время своего предыдущего запуска и время последнего добавленного события. Вспомогательные таблицы нужны, что-бы не делать select max() from таблица_событий.
Если сервер азе или SA в режиме блокировчника, то таблицу с временем последней добавленной транзакции можно читать в режиме dirty read, т.к. добавляющие процессы будут конкурировать за эту таблицу.
- Все записи с интервалом временем между предыдущим стартом и считанным текущим временем апдейтим как вам надо.
- фиксируем новый интервал времени как время предыдущего запуска скрипта.

Нужны соответственно индексы по полю времени.