Ich habe eine gespeicherte Prozedur mit einer BEGIN TRANSACTION und COMMIT TRANSACTION Anweisung. Innerhalb der Transaktion ist eine Select-Abfrage WITH(XLOCK, ROWLOCK) .
Die Transaktion kann möglicherweise aufgrund einiger Berechnungen fehlschlagen, die einen arithmetischen Überlauffehler verursachen, wenn Werte außerhalb der Grenzen geliefert werden. Dieser Fehler würde vor jeder insert / update-Anweisung auftreten.
Meine Frage ist, sollte ich die Transaktion in ein TRY / CATCH und Rollback verpacken oder ist dies nicht wirklich erforderlich und alle Sperren würden automatisch freigegeben, wenn die Transaktion fehlschlägt? Meine einzige Sorge hier ist, dass SQL nicht alle Sperren der Transaktion freigeben würde, falls die Transaktion fehlschlägt.
Danke,
Tom
Kurze Antwort: Ja.
Immer wenn ich BEGIN TRANSACTION verwende, schließe ich immer Benutzungsfehlerbehandlung und ROLLBACK ein. Die Konsequenzen eines unerwarteten (und / oder nicht vorhersehbaren - Sie können nicht wissen, wie Ihr Code in der Zukunft möglicherweise geändert werden muss) Situation, die eine offene Transaktion auf einem Produktionsserver belassen, sind zu streng, um es nicht zu tun.
In SQL Server 2000 und früher müssen Sie die Fehlerlogik @@ verwenden. In SQL 2005 und höher können Sie die (weit bessere) TRY ... CATCH ... -Syntax verwenden.
Ein viel einfacherer Weg ist:
%Vor%Dies bewirkt, dass die Transaktion automatisch zurückgesetzt wird, wenn ein Fehler auftritt.
Beispielcode:
%Vor%Wenn Sie das zweite Segment mehrmals ausführen, wird die Transaktionsanzahl auf 2,3,4 usw. erhöht. Ein einzelner Lauf des ersten Segments setzt alle Transaktionen zurück.
Ich mag Brad Ansatz, aber es brauchte ein wenig Aufräumen, damit Sie den Fehler sehen können, der das Problem verursacht hat.
%Vor%Tags und Links sql-server rollback tsql transactions