SQL Server und @@ERROR

[bigpoint]

hat da schon jemand Erfahrungen sammeln können.

A7.11. Probleme mit @@Error

Ich kann das nich nachvolziehen

Ein beispiel wehre super

Gruß

bigpoint

[Honkytonk]

Moin,

das Problem ist folgendes: @@error bezieht sich nur auf den count für die letzte Operation.

INSERT INTO [i]table[/i] VALUES (1, '[i]value[/i]')

INSERT INTO [i]table[/i] VALUES (2, '[i]value[/i]')

INSERT INTO [i]table[/i] VALUES (3, '[i]value[/i]')

INSERT INTO [i]table[/i] VALUES (4, '[i]value[/i]')


if (@error > 0)

   exec [i]procCleanUp[/i]

Falls z.B. das zweite Insert aufgrund einer Schlüssel-Verletzung knallen sollte und das vierte Insert trotzdem funktioniert, so wirst du nie in den Fehlerhandler reinlaufen. Dies gilt auch für Inserts in einer Transaction, daher ist der Tip von Jungbluth richtig:

BEGIN TRANSACTION

    -- den counter ausschalten

    -- alle folgenden operation werden nicht ausgwertet

    SET NOCOUNT ON


    INSERT INTO [i]table[/i] VALUES (1, '[i]value[/i]')

    INSERT INTO [i]table[/i] VALUES (2, '[i]value[/i]')

    INSERT INTO [i]table[/i] VALUES (3, '[i]value[/i]')

    INSERT INTO [i]table[/i] VALUES (4, '[i]value[/i]')


    -- den counter anschalten, damit geschaut werden kann 

    -- ob die ganze transaction funktioniert

    SET NOCOUNT OFF


COMMIT TRAN


if (@@error > 0)

   exec [i]procCleanUp[/i]

Da die Transaktion aufgrund der Schlüsselverletzung fehlschlagen wird, kann man auf den Fehlerfall reagieren. Andernfalls würde dir nur übrig bleiben @@error nach jedem Insert in eine Variable zu schreiben und die am Ende auszuwerten.

Gruß,

Honky

[bigpoint]

Erstmal Danke für den Antwort.

Das alles was Du hier beschrieben hast ist mit bekannt.

Ich denke jedoch dass das Problem wo anderes liegt.

In einer Stored Procedure wird der Fehlerabfang @@Error genutzt. Sobald in der Stored Procedure mit Transaction gearbeitet wird, funktioniert der Fehlerabfang nicht mehr.

Also auch wenn ich beispielsweise nach jedem insert denn @@error abfange wird er 0 sein.

Und das kann ich nicht mit einem Beispiel nachvollziehen.

Gruß

[Honkytonk]

Achso, der Sachverhalt wäre mir auch neu. Mal davon abgesehen, dass wenn es so wäre 80% unserer SP´s nicht funktionieren würden.

Hm, habs jetzt auch mehrmals probiert. Ich kann es so auch nicht nachvollziehen (SQL SERVER 2000 SP3a auf Win2000 Server). Die Abfrage auf @@error liefert immer den korrekten Wert, also auch im Fehlerfall >0.

Tippe mal drauf, dass das mit nem ServicePack behoben wurde. Werde nachher mal bei einem von unseren Microsofties fragen.

[bigpoint]

Bei mir bricht die Prozedur ab und kommt gar nicht zu dem @@error.

Kannst Du mir einen kleinen Beispiel liefern wo die Prozedur mit Fehler endet ?

[Honkytonk]

Konnte den Fehler doch reproduzieren!

Also ich hab mir auf die schnelle eine 2-spaltige Tabelle gebaut, dort die Werte 1-4 schon eingetragen. Auf der ersten Spalte liegt ein PK, d.h. er schmeisst nen Fehler wenn ich versuche doppelte Sätze einzutragen. Das sollte die unten aufgeführte Prozedur produzieren. Der Wert 99 dürfte theoretisch eingetragen werden. Da es in der Transktion steht natürlich dann doch nicht nicht.

SET QUOTED_IDENTIFIER ON 

GO

SET ANSI_NULLS ON 

GO


if exists(Select * from sysobjects where type = 'P' and name = 'sp_TestTrans')

	DROP PROCEDURE sp_TestTrans

GO


CREATE Procedure sp_TestTrans 

AS

DECLARE	@iError		int


BEGIN TRANSACTION


INSERT INTO tblTest VALUES (1,'Test1')

if (@@Error > 0)

    begin

	PRINT 'Fehler!!!' + cast(@@error as varchar)

	select @iError = @@error

    end


INSERT INTO tblTest VALUES (2,'Test1')

if (@@Error > 0)

    begin

	PRINT 'Fehler!!!' + cast(@@error as varchar)

	select @iError = @@error

    end


INSERT INTO tblTest VALUES (3,'Test1')

if (@@Error > 0)

    begin

	PRINT 'Fehler!!!' + cast(@@error as varchar)

	select @iError = @@error

    end


INSERT INTO tblTest VALUES (99,'Test99')

if (@@Error > 0)

    begin

	PRINT 'Fehler!!!' + cast(@@error as varchar)

	select @iError = @@error

    end


INSERT INTO tblTest VALUES (4,'Test1')

if (@@Error > 0)

    begin

	PRINT 'Fehler!!!' + cast(@@error as varchar)

	select @iError = @@error

    end



if @iError > 0


	ROLLBACK TRANSACTION

else


	COMMIT TRANSACTION


GO

SET QUOTED_IDENTIFIER OFF 

GO

SET ANSI_NULLS ON 

GO

Wunderlich:

Obwohl er über die Schlüssel-Verletzung meckert ist @@error = 0!

[bigpoint]

Nee das ist keine guter Beispiel,

der bricht logischer weise bei erstem insert sofort ab und mach einen rollback

Was ich meine man sollte so einen Fehler produzieren wo er nicht abbricht sondern weiter macht und dann denn @error beobachten

Ich habe schon mit Division durch Null probiert aber der schmiert auch ab.

[Honkytonk]

Nee das ist keine guter Beispiel,

der bricht logischer weise bei erstem insert sofort ab und mach einen rollback

Was ich meine man sollte so einen Fehler produzieren wo er nicht abbricht sondern weiter macht und dann denn @error beobachten

Ich habe schon mit Division durch Null probiert aber der schmiert auch ab.

Nein, automatisch sollte er die Transkation nicht abbrechen. Sei es drum, auch in diesem Fall sollte er den Fehlercode in @@error tragen, oder?

[Edit]

Habe dazu noch folgenden Knowledgebase-Artikel gefunden, der damit zusammenhängen könnte: http://support.microsoft.com/kb/890925

[/Edit]

[bigpoint]

Nein, automatisch sollte er die Transkation nicht abbrechen. Sei es drum, auch in diesem Fall sollte er den Fehlercode in @@error tragen, oder?

stimmt die Prozedur läuft weiter

allerdings Set Nocount On bringt auch nichts :confused:

[bigpoint]

[Edit]

Habe dazu noch folgenden Knowledgebase-Artikel gefunden, der damit zusammenhängen könnte: http://support.microsoft.com/kb/890925

[/Edit]

hast Du die Seite auch auf englisch ?

[Honkytonk]

hast Du die Seite auch auf englisch ?

Öhm, Knöpfchen drücken oben rechts bringt uns zu:

http://support.microsoft.com/kb/890925/en-us