Это не настоящий дедлок, это конфликт обновления одной и той же записи из двух разных транзакций.

Берете HQbird PerfMon, запускаете трейс, ждете момента, когда произошел облом, фиксируете (лучше всего в приложении).
Затем в БД лога PerfMon скрупулезно смотрите все открытые на тот момент транзакции, и в них смотрите выполняющиеся UPDATE или DELETE, далее сопоставляете с обломившимся и вуаля.

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

С уважением,
Алексей Ковязин
www.ibase.ru