De sortie et de retour en arrière tout en script en cas d'erreur

J'ai un script TSQL qui fait beaucoup d'ajustements de la structure de la base de données mais ce n'est pas vraiment sûr que de laisser aller de travers quand quelque chose tombe en panne.

à mettre les choses au clair:

à l'aide de MS SQL 2005
ce n'est PAS une procédure stockée, juste un fichier de script (.sql)

ce que j'ai, c'est quelque chose dans l'ordre suivant

BEGIN TRANSACTION
    ALTER Stuff
    GO

    CREATE New Stuff
    GO

    DROP Old Stuff
    GO
IF @@ERROR != 0
    BEGIN
  PRINT 'Errors Found ... Rolling back'
  ROLLBACK TRANSACTION
  RETURN
    END
ELSE
     PRINT 'No Errors ... Committing changes'
     COMMIT TRANSACTION

juste pour illustrer ce que je suis en train de travailler avec ... ne peut pas aller dans les détails
maintenant, le problème ...

Quand je introduire une erreur (pour tester si les choses se roula en arrière), j'obtiens une déclaration que le ROLLBACK TRANSACTION ne pouvait pas trouver un correspondant de COMMENCER l'OPÉRATION.
Cela me mène à croire que quelque chose de VRAIMENT mauvais et que la transaction a déjà été tué.
ce que j'ai aussi remarqué, c'est que le script n'a pas de quitter complètement en erreur et N'a donc essayez d'exécuter chaque instruction après l'erreur s'est produite. (Je l'ai remarqué lorsque de nouvelles tables ont montré jusqu'à quand je ne m'y attendais pas, car il doit avoir rollbacked)

OriginalL'auteur Jan W. | 2010-05-26

7

Lorsque l'erreur se produit, la transaction est annulée automatiquement, et le lot en cours est annulée.

L'exécution se poursuit dans le lot suivant, cependant. Donc tous les trucs dans les lots après l'erreur est exécuté. Et puis, quand vous vérifiez les erreurs plus tard, vous essayez pour la restauration d'un déjà roulé sur le dos de la transaction.

Aussi, pour arrêter le script en entier, pas seulement le lot en cours, vous devez utiliser:
```
raiserror('Error description here', 20, -1) with log
```
Voir ma réponse ici pour plus de détails sur celle-ci.

De sorte que vous devez vérifier pour @error après chaque lot, je pense que quelque chose comme cela devrait fonctionner:
```
BEGIN TRANSACTION
GO

ALTER Stuff
GO

if @@error != 0 raiserror('Script failed', 20, -1) with log
GO

CREATE New Stuff
GO

if @@error != 0 raiserror('Script failed', 20, -1) with log
GO

DROP Old Stuff
GO

if @@error != 0 raiserror('Script failed', 20, -1) with log
GO

PRINT 'No Errors ... Committing changes'
COMMIT TRANSACTION
```
c'est en gros ce que j'ai utilisé, mais dans la forme suivante: si @@error <> 0 ou @@trancount = 0 de commencer si @@trancount > 0 restauration de l'ensemble de transactions noexec sur la fin
set noexec on est un truc intéressant, doivent se rappeler que.
Est-ce de travailler avec un serveur de transaction tels que DROP LOGIN? Je veux changer de domaine d'un compte de connexion appartient et je suis tomber à partir de bases de données, mais besoin de recréer tout en veillant à ce que RIEN n'est tombé si CHAQUE transaction est validée avec succès. Ce résultat serait mal mappé autorisations, etc. et ce serait une catastrophe.
Il semble que le travail: j'ai juste couru un script begin transaction; drop login [pc\user]; raiserror('Script failed', 20, -1) with log - la connexion n'a pas été supprimée (assurez-vous que vous êtes connecté en tant que sa avant de le faire bien, ou raiserror échoue et le script va continuer!)
Qui ne fonctionne que si truc est une instruction unique. Le @@ERROR retourne un seul résultat de la dernière instruction exécutée, donc si truc se compose de plusieurs états, seulement une erreur sur la dernière déclaration de provoquer ce genre d'erreur de manipulation à effectuer. TRY...CATCH est mieux.

OriginalL'auteur Blorgbeard

Essayez de RETOUR. cette sortie du script ou de la procédure et de ne pas exécuter les instructions suivantes. Vous pouvez l'utiliser en conjonction avec COMMENCER, de RESTAURATION et de COMMETTRE des déclarations de TRANSACTION à annuler les dommages de données:

    BEGIN
    BEGIN TRANSACTION

    <first batch>
    IF @@error <> 0
        begin
        RAISERROR ('first batch failed',16,-1)
        ROLLBACK TRANSACTION
        RETURN
        end

    <second batch>
    IF @@error <> 0
        begin
        RAISERROR ('second batch failed',16,-1)
        ROLLBACK TRANSACTION
        RETURN
        end

    PRINT 'WIN!'
    COMMIT TRANSACTION
    END

OriginalL'auteur A___

3

Je n'ai pas utilisé le raiseerror solution, parce qu'elle a échoué car je n'ai pas disposer des autorisations d'administrateur. J'ai étendu la noexec on/off de la solution à l'opération de manutention comme suit:
```
set noexec off

begin transaction
go

<First batch, do something here>
go
if @@error != 0 set noexec on;

<Second batch, do something here>
go
if @@error != 0 set noexec on;

<... etc>

declare @finished bit;
set @finished = 1;

SET noexec off;

IF @finished = 1
BEGIN
    PRINT 'Committing changes'
    COMMIT TRANSACTION
END
ELSE
BEGIN
    PRINT 'Errors occured. Rolling back changes'
    ROLLBACK TRANSACTION
END
```
Apparemment le compilateur "comprend" la @terminé variable dans le SI, même si il y avait une erreur et que l'exécution a été désactivé. Toutefois, la valeur est définie sur 1 que si l'exécution n'a pas été désactivé. Donc je peux bien commit ou rollback de la transaction en conséquence.

OriginalL'auteur Tz_

Vous pouvez essayer quelque chose comme ça... Si vous utilisez le bloc Try... Le niveau d'erreur 16, (ou la plupart d'erreur d'application), transfère immédiatement le contrôle pour le bloc CATCH sans exécuter d'autres déclarations dans le bloc try...

    Begin Transaction

Begin Try

                    --  Do your Stuff

        If (@@RowCount <> 1) -- Error condition
        Begin
            Raiserror('Error Message',16,1)
        End


    Commit
End Try
Begin Catch
    IF @@Trancount > 0
    begin
        Rollback Transaction
    End

    Declare @ErrMsg varchar(4000), @Errseverity int

    SELECT @ErrMsg = ERROR_MESSAGE(),
          @ErrSeverity = ERROR_SEVERITY()

    RAISERROR(@ErrMsg, @ErrSeverity, 1)     
End Catch

Espère que cela aide...

Vous ne pouvez pas avoir GO états à l'intérieur d'un TRY-CATCH: msdn.microsoft.com/en-us/library/ms179296.aspx

OriginalL'auteur The King

SET XACT_ABORT ON
BEGIN TRAN

-- Batch 1

GO

if @@TRANCOUNT = 0 
SET NOEXEC ON;
GO

-- Batch 2

GO

if @@TRANCOUNT = 0 
SET NOEXEC ON;
GO

-- Batch 3

GO

if @@TRANCOUNT > 0 
COMMIT
GO

OriginalL'auteur Edward Olamisan

Vous devez vous connecter pour publier un commentaire.