TSQL- Stored Procedure

[NGA 0]

Hallo,

 

wir besitzen einen SQL- Server 2012 der auf einem Windows Server 2012 R2 läuft.

 

Im Unternehmen werden einige Access- Programme für beispielsweise Abwesenheitsliste, Urlaubsprogramm usw. verwendet.

Access dient hier als Front- End.

 

Via einer eigens entwickelten Verbindungsklasse (ADO)  wird die Verbindung zwischen Front- End und Back- End hergestellt. 

Stored Procedures dienen dann zur Abhandlung von Datenbankeinträgen, -updates oder -löschungen. 

 

Nun ist es aber so, dass wir bei manchen Aktionen an den Client eine Fehler-/Infomeldung anzeigen lassen wollen.

Verwendet werden soll hier die TSQL- Funktion "THROW".

Fehlermeldungen anzuzeigen ist kein Problem. 

 

Bei Infomeldungen haben wir folgendes überlegt:

if @proctype = 3 -- check how info messages thrown
	BEGIN
		BEGIN TRANSACTION t1;
		BEGIN TRY
			-- Step 1
				INSERT INTO AccessTests.dbo.excp_test (test_text) VALUES ('t');
			-- Step 2
				INSERT INTO AccessTests.dbo.excp_test2 (test_text2) VALUES ('test');

				
				COMMIT TRANSACTION t1;
				THROW 53000, '200INFO! Daten erfolgreich gespeichert', 1
				
		END TRY
		BEGIN CATCH
			--PRINT 'Catch block2';
			IF @@TRANCOUNT > 0
			ROLLBACK TRANSACTION t1;
			THROW;
		END CATCH
	END 

Sobald die beiden INSERTs ok sind, wird ein COMMIT der Transaktion t1 durchgeführt. Somit ist die Transaktion abgeschlossen.

Über THROW wird nun eine Meldung erzeugt, die an den Client (Access- Programm) zurückgeliefert wird. 

Dadurch, dass THROW aber eigentlich verwendet wird, um Fehler zurückzugeben, springt das Skript in den CATCH- Block.

Die Prüfung bezüglich dem @@TRANCOUNT (prüft, Anzahl von BEGIN TRANS...) verhindert, dass ein ROLLBACK der vorher positiv abgewickelten SQL- Queries durchgeführt wird. 

 

Nun könnten wir die Meldung, die vom SQL- Server zurückgeliefert wird in unserer VBA- Verbindungsklasse parsen und prüfen, ob das Muster "200INFO!" darin enthalten ist. 

Dadurch können wir den Programmablauf besser steuern --> Recordset = true und nicht false. 

 

Gibt es eine schönere Variante? Wasw meint ihr dazu?

Hab schon einige Einträge im Internet durchsucht, aber nichts besseres gefunden. 

 

Ich bedanke mich schon einmal für eure Antworten.

bearbeitet 13. März 2015 von NGA

[zahni 550]

Hi,

 

mir erschließt sich die Sinnhaftigkeit der Prozedur nicht. Wenn der Insert fehlschlägt, muss Du kein Rollback machen. Das die der SQL-Server schon alleine. 

Das obige Beispiel sollte man eigentlich ohne diese Prozedur ausführen können. Das Error-Handling kann man auch im Access realisieren und dann  hübsche Fehlermeldungen ausgeben.

 

-Zahni

[NGA 0]

Hallo, 

 

das ist nur eine kleine Test Prozedur :) , um zu sehen wie sich THROW etc. überhaupt auswirkt. Man gehe davon aus, die Queries wären voneinander abhängig.

 

Vorher sah die Prozedur so aus, um einen Fehler zu provozieren: (Null- Werte werden in der Spalte "test_text" nicht erlaubt)

-- Step 1
    INSERT INTO AccessTests.dbo.excp_test (test_text) VALUES (null);
-- Step 2
    INSERT INTO AccessTests.dbo.excp_test2 (test_text2) VALUES ('test');

Dann wird eine Fehlermeldung richtig zurückgegeben. Uns ging es nur um die Infomeldungen. 

 

Wir wollen in Zukunft die meiste Programmlogik auf dem SQL- Server in den Prozeduren lassen,

um Grund- Funktionen nicht im Access Programm haben zu müssen, die dann einen neuen Rollout des Programmes erfordern. 

 

Dadurch dass aber RAISERROR (veraltet seit 2012) und THROW eine Meldung vom Typ Error an unsere VBA Klasse liefert,

müssen wir darin prüfen, ob "200Info" in der zurückgegebenen Meldung enthalten ist. Wenn ja --> Kein Fehler - Wenn nein: Fehler 

bearbeitet 13. März 2015 von NGA

[zahni 550]

Dann würde ich mir mal https://msdn.microsoft.com/en-us/library/ms178649.aspx  anschauen.

 

Generell würde ich das Verfahren aber nochmal überdenken. SQL ist keine Programmiersprache und dient nur einem bestimmen Zweck.

Auch würde aber öfter eher was an der GUI ändern müssen als am SQL-Code. Eine Spalte mehr bedeutet meist auch eine Anpassung der GUI.