2012-01-03 2 views
6

W SQL Server 2008, używam wzorzec takiego:transakcja jest wciąż otwarta po anulowaniu zapytania

begin transaction 

begin try 

/* do something */ 

end try 

begin catch 

if @@TRANCOUNT > 0 
rollback 

DECLARE @ErrMsg nvarchar(4000), @ErrSeverity int        
    SELECT @ErrMsg = ERROR_MESSAGE(),        
     @ErrSeverity = ERROR_SEVERITY()        

    RAISERROR(@ErrMsg, @ErrSeverity,1)  

end catch 

if @@TRANCOUNT > 0 
commit transaction 

gdy uderzę „Cancel wykonujące zapytania” przycisk na SQL Server Management Studio to anuluje zapytanie i liści transakcja jest otwarta.

Czy to jest zamierzone zachowanie? Czy jest jakiś błąd w moim wzorze? Czy nie powinien on wycofać transakcji?

Odpowiedz

9

IMHO, to zamierzone zachowanie. Gdy anulujesz uruchamianie kwerendy, jeśli była otwarta transakcja - pozostaje otwarta do momentu jej jawnego zatwierdzenia lub wycofania, dopóki nie zostanie zamknięte połączenie

Nie ma żadnych cennych błędów we wzorcu. Jeśli ręcznie sterujesz przepływem wykonawczym (Anuluj wykonywanie kwerendy), powinieneś zadbać o otwarte transakcje w ten sam sposób - ręcznie.

Aktualizacja:

zachowanie jest kontrolowane przez SSMS opcja Disconnect po zapytaniu wykonuje - co oznacza, że ​​rozłącza zapytań po wykonaniu lub anulować i wycofuje otwarte transakcje:

+0

zobaczyć zaktualizowana odpowiedź –

+2

Ta odpowiedź wydaje się omijać ducha pytania ... Pytanie może zostać zmienione na: "Dlaczego anulowanie zapytania nie wyzwala bloku" catch "konstrukcji typu try/catch?" Jeśli to zamierzone zachowanie, dlaczego? Jako projektant tego procesu oczekuję, że proces zakończy się pomyślnie lub zostanie wycofany - domniemana semantyka try/catch nie pozwala na "zatrzymanie wykonywania, ale nie martw się blokiem catch i pozostaw transakcję otwartą aż do serwera SQL postanawia oczyścić trasaction po rozłączeniu "... Zdrowe zachowanie byłoby z pewnością wywołać" błąd anulowania "? – Tao

+0

@Tao Może masz rację, ale autor przyjął odpowiedź, proszę, nie myśl za niego. –