Fehlerbehandlung von Stored Procedures

[alzaimar]

Hi

Kleines Problem, wenig Zeit (deshalb müsst ihr ran )

Ich habe auf dem Papier eine Stored Procedure, die wird über ADO irgendwie aufgerufen. Diese SP übermittelt Daten an einen anderen Server (mit INSERT). Nun kann es sein, das der andere Server nicht erreichbar ist. Dann soll die SP die Daten lokal zwischenspeichern.

Die Tatsache, ob das der Server nicht erreichbar ist, ermittle ich einfach über die @@Error-Variable (wenn's knallt, dann lokal zwischenspeichern). Das sollte auch funktionieren.

Ich will nun aber nicht, das dieser (und nur dieser!) Fehler an ADO zurückgemeldet wird.

Frage: Kann man die Generierung der Fehlermeldung auf SQL-Seite ausschalten, sodaß ADO davon nix mitbekommt, also so ne Art 'Try...Except End', oder 'ON ERROR CONTINUE'?

Die Alternative wäre, die Daten immer zwischenzuspeichern, und dann über einen separaten Task (z.B. jede Minute) die lokalen Daten zu übermitteln, der Kunde würde aber lieber die direkte Übermittlung sehen (ja ja, wenn die Kunden nicht wären).

[alzaimar]

Muss untergegangen sein (push).

Hat Jemand eine Idee?

[PaulJr]

Hallo Alzamir,

ich bezweifle, dass Du die (SQL) Fehlermeldung so einfach unterdrücken kannst.

Ich benutze ADO nicht aber die Mechanismen sollten überall die Gleichen sein: Darum, ich z.B. erkenne nicht nur solche Fehler in entsprechenden Ereignissen sondern (um diese zu unterdrücken) behandle diese auch…

Viele Grüße
PaulJr

[alzaimar]

Hau Paul,

ich bezweifle das auch, bin aber nicht allwissend. Ich habe gehofft, irgendeine obskure 'SET ERROR OFF' - Einstellung würde MSSQL das Maul stopfen. Ich befürchte, ich muss die Mittelschicht anfassen, was tödlich sein kann ('Never touch a running system').

Nun denn, Suizid als Hobby. Auch was neues.

[Phoenix]

Strukturierte Fehlerbehandluung kennt der SQL Server 2000 nicht. Sorry. Das geht erst ab SQL Server 2005.

[Elvis]

Würde es nicht mehr Sinn machen, das Ganze in einer nativen XProc zu lösen?
TSQL ist doch für alles jenseits einem SELECT und einer if-Clause viel zu drecks-eklig.
Gerade die Fehlerbehandlung wird keiner außer dir kapieren können...

[Jelly]

Du kannst, wie du ja schon machst, über @@error den Fehler abfragen. Speichere den Wert in einer Zwischenvariablen und prüfe anschliessend über

SQL-Code:

if @myError <> 0 BEGIN
   goto ErrorHandler
END

-- Hier der normale Ablauf
Goto ExitProc

ErrorHandler:
Rollback Tran
return


ExitProc:
return

deinen Fehler.
Laut meinem Buch wird beim Fehler zum Label ErrorHandler gesprungen. Dort kannst du auf jeden Fall noch ein paar Aktionen durchführen. Ob der Return allerdings nun dennoch einen Fehler auf Clientseite auslöst, weiss ich nicht.

Hast du vielleicht eine Möglichkeit einen SQL Server der Version 2005 zu nutzen. Dort gibts ein neues Errorhandling über Try...catch Blöcke wie man sie von anderen Programmiersprachen her kennt. Da wird auf jeden Fall die Fehlermeldung beim Client unterbunden. Soll sie dennoch ausgelöst werden, reicht ein erneuter Raiserror im Catch-Block.

[Jelly]

Zitat von Elvis:

Gerade die Fehlerbehandlung wird keiner außer dir kapieren können...

Robert, du weisst aber schon dann man auch eigene Fehlermeldungen definieren kann... Sogar parametrisiert.

[alzaimar]

Ich arbeite ausgiebig mit eigenen benutzerdefinierten Fehlermeldungen, das funktioniert wunderbar. Ich war/bin auf Version 2000 eingeschossen, sodaß der Hinweis auf den TRY-CATCH-Block der 2005er die Lösung meines Problemes darstellen könnte.

Ich glaub sogar, das Zielsystem ist ein 2005er, nur die Testumgebung (noch) eine alte Gurke.


Danke für den Hinweis!

[Jelly]

Dann haste ja noch mal die letzte Ausfahrt erwischt