Оператор удаления SQL не удалил - PullRequest
0 голосов
/ 31 октября 2011

Просто хочу получить несколько просмотров / потенциальных клиентов по моей проблеме.

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

Однако недавно я работал над службой Windows для мониторинга нашей системы (работающей 24/7), которая использует HTTP-вызов для запуска программы, и когда эта программа завершает свою работу, она запускает упомянутую хранимую процедуру дляудалить лишние данные.В основном служба просто быстро запускает программу, чтобы убедиться, что она работает правильно.

Недавно я заметил, что данные не всегда удаляются.Просматривая логи, я не вижу сообщений об ошибках.И даже увидеть запись в базе была обновлена ​​правильно.Но просто не удаляется.

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

В настоящее время у меня есть процедура для очистки любых старых данных.(3 часа).

Результат имеет значение - Отклонено.

Ниже представлена ​​хранимая процедура:

    DECLARE @PostponeUntil DATETIME;
DECLARE @Attempts INT;
DECLARE @InitialTarget VARCHAR(8);
DECLARE @MaxAttempts INT;
DECLARE @APIDate DATETIME;

--UPDATE tCallbacks SET Result = @Result WHERE CallbackID = @CallbackID AND UPPER(Result) = 'PENDING';

UPDATE tCallbacks SET Result = @Result WHERE ID = (SELECT TOP 1 ID FROM tCallbacks WHERE CallbackID = @CallbackID ORDER BY ID DESC)

SELECT @InitialTarget = C.InitialTarget, @Attempts = LCB.Attempts, @MaxAttempts = C.CallAttempts
FROM tConfigurations C WITH (NOLOCK)
LEFT JOIN tLiveCallbacks LCB ON LCB.ID = @CallbackID
WHERE C.ID = LCB.ConfigurationID;

IF ((UPPER(@Result) <> 'SUCCESSFUL') AND (UPPER(@Result) <> 'MAXATTEMPTS') AND (UPPER(@Result) <> 'DESTBAR') AND (UPPER(@Result) <> 'REJECTED')) BEGIN
    --INSERT A NEW RECORD FOR RTNR/BUSY/UNSUCCESSFUL/REJECT
    --Create Callback Archive Record

    SELECT @APIDate = CallbackRequestDate FROM tCallbacks WHERE Attempts = 0 AND CallbackID = @CallbackID;

    BEGIN TRANSACTION 
    INSERT INTO tCallbacks (CallbackID, ConfigurationID, InitialTarget, Agent, AgentPresentedCLI, Callee, CalleePresentedCLI, CallbackRequestDate, Attempts, Result, CBRType, ExternalID, ASR, SessionID)
        SELECT ID, ConfigurationID, @InitialTarget, Agent, AgentPresentedCLI, Callee, CalleePresentedCLI, @APIDate, @Attempts + 1, 'PENDING', CBRType, ExternalID, ASR, SessionID
        FROM tLiveCallbacks
        WHERE ID = @CallbackID;

    UPDATE LCB 
    SET PostponeUntil = DATEADD(second, C.CallRetryPeriod, GETDATE()),
        Pending = 0,
        Attempts = @Attempts + 1
    FROM tLiveCallbacks LCB
    LEFT JOIN tConfigurations C ON C.ID = LCB.ConfigurationID
    WHERE LCB.ID = @CallbackID;

    COMMIT TRANSACTION
END
ELSE BEGIN
    -- Update the Callbacks archive, when Successful or Max Attempts or DestBar.
    IF EXISTS (SELECT ID FROM tLiveCallbacks WHERE ID = @CallbackID) BEGIN

        BEGIN TRANSACTION
        UPDATE  tCallbacks 
        SET Attempts = @Attempts 
        WHERE ID IN (SELECT TOP (1) ID 
                             FROM tCallbacks 
                             WHERE CallbackID = @CallbackID 
                             ORDER BY Attempts DESC);

        -- The live callback should no longer be active now. As its either been answered or reach the max attempts.
        DELETE FROM tLiveCallbacks WHERE ID = @CallbackID;
        COMMIT
    END
END

1 Ответ

2 голосов
/ 31 октября 2011

Вам необходимо исправить обработку транзакции. Происходит то, что один оператор терпит неудачу, но поскольку у вас нет блока try-catch, все изменения не откатываются, только оператор, который потерпел неудачу.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...