Деадлоки при использовании SQL Server

[DeSp]

Опишу ситуацию подробнее:
Одноврменно запускаю одинаковую операцию на двух клиентах. Как правило, один из клиентов отключается сервером из-за дедлока, а второй успешно заканчивает свою транзакцию. Но, бывают мертвые зависы, когда оба клиента висят до тех пор (как минимум час), пока вручную не отключить одного из них - блокирующего, убив его процесс, тогда блокируемый также успешно заканчивает транзакцию. Информация по процессам мертвого зависа реглуярно обновляется в Enterprise Manager -> Process Info на протяжении всего времени зависа:

client1: spid=56, status=sleeping, open transactions=0, command=awaiting command, wait time=0, wait type=not waiting, wait resource=..., blocked by=0, blocking=1

client2: spid=55, status=sleeping, open transactions=1, command=execute, wait time=0, wait type=miscellaneous, wait resource=..., blocked by 56, blocking=0

Резалтсет процедуры sp_lock по 56 показывает, что он получил все необходимые ему ресурсы (status=GRANT), а 57 ждет освобождения ключа (status=WAIT).

В трассе профайлера в таком случае также обнаруживаются все полагающиеся ивенты для дедлока, по времени совпадающего с моментом времени зависа: Lockeadlock Chain, Lockeadlock и Exception (Error=1205, Severity=13, State=50) для блокирующего процесса. То есть сервер выбрал блокирующего жертвой дедлока и должен был откатить его транзакцию, а значит освободить заблокированные им ресурсы, нужные для продолжения транзакции блокируемого. Но клиенты продолжают висеть! Видимо по какой-то причине ресурсы блокирующего не были освобождены, а транзакция не была откатана. Если это был дедлок (а трасса говорит что был) то почему клиенты продолжают висеть? В чем может быть проблема?

Кроме того, если мониторить выполнение операции с помощью средств Navision (Code coverage, Client Monitor, Client Monitor (Multi-User) согласно инструкции "Performance troubleshooting guide.pdf", то у блокирующего клиента в момент времени зависа в логе появляется ошибка [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()). О чем говорит данная ошибка?

При мертвом зависе и последующем убивании вручную блокирующего процесса 56 его клиент иногда выдает сообщение вида: "Внутрення ошибка 1247 в модуле 19, обртитесь к вашему дилеру, если нужна помощь." Что это за ощибка?