Доброго всем времени суток !
Возникла проблема со stored procedure , доставшейся "по наследству"
Общий вид SP:
CREATE PROCEDURE sp_Compute
AS
DECLARE .... /* объявление переменных */

BEGIN TRANSACTION T1
DECLARE OrderPositionCursor CURSOR FAST_FORWARD
FOR SELECT * FROM OrderPosition with(nolock)
OPEN tblOrderPosition
FETCH NEXT FROM OrderPositionCursor into @SourceId, ....

BEGIN TRANSACTION T2
WHILE (@@fetch_status = 0)
BEGIN
/* Собственно логика обработки */

SkipOrderPosition:
IF @iCounter % 1000 = 0
BEGIN
/* Промежуточная фиксация обработанных данных */
COMMIT TRANSACTION T2
/* вывод служебной информации и старт транзакции */
BEGIN TRANSACTION T2
END
SET @iCounter = @iCounter + 1
FETCH NEXT FROM OrderPositionCursor INTO @SourceId, ....
END
COMMIT TRANSACTION T2
CLOSE OrderPositionCursor
DEALLOCATE OrderPositionCursor
COMMIT TRANSACTION T1

Суть проблемы:
Среда - Windows 2000 Adv.server (German) , MS SQL Server 7.0 (German)
В процессе работы процедура в непредсказуемый момент времени финиширует без каких-либо сообщений об ошибках, оставляя незакрытыми транзакции T2 и T1. Соответственно, ресурсы, к которым она обращалась, остаются заблокированными.
Если в Enterpr.Managere убить процесс (либо закрыть программу, вызвавшую эту sp ), то T1 откатывается назад и сносит результаты расчета.
Попытка оттрассировать ни к каким результатам не привела. При запуске в QA как самого кода, так и процедуры с теми же параметрами, которые идут от вызывающей программы - никаких проблем. При запуске на MS SQL Server 2000 - так же все в ажуре. Проблема возникает только на "семерке".
Процедура используется более 2 лет и подозрений до сих пор не вызывала.

Буду признателен за любые идеи, версии и советы.

2Владимир
И что это решает? @iCounter - это просто счетчик обработанных записей ... значение которого периодически (сразу после фиксации порции обработанных данных)скидывается в отдельную табличку, чтобы иметь возможность отслеживать процесс обработки. Да и вопрос-то был не об этом ... Непонятно, почему так повела себя хранимая процедура . Проблема возникла на короткой порции данных (таблица около 60000 строк), хотя ранее и 4 млн записей обрабатывалось без проблем. Возможно, кто-то сталкивался с подобной проблемой ("тихим" вылетом из sp) при вложенных транзакциях, или при использовании транзакций совместно с курсорами , как бы идиотски это не звучало. Я сам пока не знаю, с какой стороны к проблеме подступиться - при трассировке либо при отдельном запуске sp с параметрами (специально в отладчике прошелся по проге, чтобы получить , что же точно она передает как параметры при вызове sp)- все прекрасно и никаких проблем ! Сложности возникают, когда в штатном режиме sp вызывается из exe-шника.
Перенести обработку с SQL7 на SQL2000 по ряду причин я пока не могу. Так что надо разбираться.
Вызывает смутные сомнения, правильно ли то, что транзакция T2 первый раз открывается ДО входа в цикл, затем ВНУТРИ цикла закрывается и открывается вновь, чтобы закрыться уже ЗА пределами цикла. Формально это влиять не должно, но возможно, в силу каких-то особенностей реализации "семерки" эта конструкция некорректна . С другой стороны, она достаточно долго отработала, и проблем не вызывала.
Так что вопрос пока открыт.

Дополнение к предыдущему постингу.
/* Собственно логика обработки */ - этот комментарий заменяет собой много-много строчек с простыми, преимущественно математическими операциями. На возможность некорректного типа данных либо превышения размерности уже проверил - не то. Похоже, проблема кроется именно в обработке транзакций, но в чем суть - понять пока не могу.