Hallo Andreas,
Die Fehlermeldung wird immer (an den Client) zurückgegeben, @@ERROR wird nur zusätzlich gesetzt.
Außerdem gilt
@@ERROR (und auch @@ROWCOUNT) werden durch jede Anweisung neu gesetzt,
deswegen musst Du sie sofort nach der Ausführung sichern, wenn Du später darauf zurückgreifen willst.
Mehr siehe http://www.sommarskog.se/error_handling_2005.html ff.
Das wäre aber der kleinere Teil.
Wenn Du nicht was Wesentliches ausgelassen hast, ist jedoch sp_executesql hier überflüssig.
Man kann Parmeter direkt verwenden, der Einsatz von sp_executesql wäre nur notwendig,
wenn dort Teile wie Tabellen- oder Spaltennamen variabel wären.
Und dann wären oft unterschiedlichen Prozeduren günstiger.
Zudem vermute ich. dass die Parameter der Prozedur zum Teil vom Typ integer bzw. DateTime sind.
Für eine zuverlässigen Übergabe solltest Du die Parameter entsprechend der Tabellendefinition deklarieren -
nur so bemerkst Du Fehler frühzeitig.
Ansonsten treten Fehler erst bei der Ausführung der Prozedur auf entweder beim Zusammenbau oder während des sp_executesql.
Andere Dinge wie SQL Injection und Probleme mit der Rechtevergabe mal außen vorgelassen.
Für eine Flusssteuerung kann man nun über die Auswertung von @@ERROR
oder aber ab SQL Server 2005 auch über BEGIN TRY arbeiten
Mehr dazu siehe
Verwenden von TRY...CATCH in Transact-SQL
Dein Code - mit einigen Annahmen - zunächst mit manueller Fehlerbehandlung:
CREATE PROCEDURE [dbo].[mySP]
@OK1 bit,
@OK2 bit,
@OK3 bit,
@Gehr nvarchar(50),
@ID_S nvarchar(50), -- oder doch eher int???
@ID_V nvarchar(50),
@ID_D nvarchar(50),
@erfassungsdatum nvarchar(30) -- besser evtl. DateTime(2) oder Date???
AS
SET NOCOUNT ON;
DECLARE @Err int;
BEGIN TRANSACTION;
IF @OK1 = 1
BEGIN
INSERT INTO Tab1 (ID_S, Status, Erfassungsdatum)
VALUES (@ID_S, 5, + @erfassungsdatum);
SET @Err = @@ERROR;
IF @Err = 0
BEGIN
INSERT INTO Tab1_Daten (ID_S, Wert1, archiv)
VALUES (@ID_S, 1, 0);
SET @Err = @@ERROR;
END
IF @Err <> 0
BEGIN
IF @@TRANCOUNT > 0 ROLLBACK;
RETURN 1; -- besser immer: 1 Fehler, 0 OK
END
END ELSE BEGIN
SELECT ID FROM Tab1_Daten WHERE archiv = 0 AND ID_S = @ID_S;
END
COMMIT;
RETURN 0; -- OK
GO
und wenn das lässt sich mit BEGIN TRY weiter vereinfachen:
CREATE PROCEDURE [dbo].[mySP]
@OK1 bit,
@OK2 bit,
@OK3 bit,
@Gehr nvarchar(50),
@ID_S nvarchar(50), -- oder doch eher int???
@ID_V nvarchar(50),
@ID_D nvarchar(50),
@erfassungsdatum nvarchar(30) -- besser evtl. DateTime(2) oder Date???
AS
SET NOCOUNT ON;
BEGIN TRY
BEGIN TRANSACTION;
IF @OK1 = 1
BEGIN
INSERT INTO Tab1 (ID_S, Status, Erfassungsdatum)
VALUES (@ID_S, 5, + @erfassungsdatum);
INSERT INTO Tab1_Daten (ID_S, Wert1, archiv)
VALUES (@ID_S, 1, 0);
END ELSE BEGIN
SELECT ID FROM Tab1_Daten WHERE archiv = 0 AND ID_S = @ID_S;
END
COMMIT;
RETURN 0;
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0 ROLLBACK;
RETURN 1 -- besser immer: 1 Fehler, 0 OK
END CATCH
GO
Dazu die (Pseudo-)Tabellen und der (rudimentäre) Testcode, die ich verwendet habe:
USE tempdb;
GO
CREATE TABLE Tab1 (
ID_S int NOT NULL PRIMARY KEY,
Status int NOT NULL,
Erfassungsdatum Datetime);
CREATE TABLE Tab1_Daten (
ID int IDENTITY (1, 1) NOT NULL PRIMARY KEY,
ID_S int NOT NULL,
Wert1 int NOT NULL,
Archiv int NOT NULL);
GO
/*** Hier das jeweilige CREATE PROC einfügen ***/
-- Testcode
DECLARE @rc int
EXEC @rc = dbo.mySP
@OK1 = 1,
@OK2 = 0,
@OK3 = 0,
@Gehr = '',
@ID_S = 4711,
@ID_V = NULL,
@ID_D = NULL,
@erfassungsdatum = '20110609';
SELECT @rc;
EXEC @rc = dbo.mySP
@OK1 = 1,
@OK2 = 0,
@OK3 = 0,
@Gehr = '',
@ID_S = 4712,
@ID_V = NULL,
@ID_D = NULL,
@erfassungsdatum = '20110609';
SELECT @rc;
EXEC @rc = dbo.mySP
@OK1 = 0,
@OK2 = 0,
@OK3 = 0,
@Gehr = '',
@ID_S = 4711,
@ID_V = NULL,
@ID_D = NULL,
@erfassungsdatum = NULL;
SELECT @rc
GO
-- Aufräumen
DROP PROC mySP;
GO
DROP TABLE Tab1, Tab1_Daten
GO
Wie Du sehen solltest, wird insbesondere im Falle mit BEGIN TRY das Ganze deutlich übersichtlicher,
insbesondere wenn noch zwei weitere Tabellen ähnlich abgehandelt werden.
Gruß Elmar
