Rückkanal

Rückkanal: Status- und Fehlermeldungen der Datenbank zurück an den Client

Da viele Prozesse zum Großteil oder komplett in der Datenbank umgesetzt werden, fehlt dem Anwender häufig das Feedback. Zum Beispiel könnte eine Speichervorgang fehlschlagen, da bestimmte benötigte Felder nicht oder nicht richtig ausgefüllt worden. Damit das das Ergebnis solcher Plausibilitätsprüfungen, Fehler, etc. beim Client ankommt und dem Benutzer als Dialog angezeigt werden kann, gibt es eine Möglichkeit direkt aus SQL-Code.

Die RAISERROR-Funktion (ein ‘e’!) wird dabei vom easyLogic-Web-Service abgefangen, der die Meldung weiter auswertet und dann kategorisiert an den Client weitergibt. Dabei gibt es folgende zwei prinzipiellen Unterscheidungen:

• ob die Meldung rein informativen Wert hat, oder einen Fehler darstellt, der das Speichern verhinderte,
• ob der Fehler interner Natur ist — z.B. ein Speicherplatz-Problem beim Datenbank-Server — (und damit die meisten Benutzer nur eine allgemeine, unspezifische Meldung erhalten), oder dessen Einzelheiten für alle Benutzer sichtbar sein sollten.

Eine solche Rückmeldungen lässt sich ab easyLogic 3.0.6 einsetzen, sobald Feldinhalte gespeichert oder ein Button-Feld geklickt wurde. Im ersteren Fall bietet sich dabei ein Trigger auf der entsprechenden zz-Tabelle an; bei letzterem ist die im Editor angegebene Stored Procedure (Eigenschaft Aktion) geeignet.

Im SQL-Code sieht das ganze dann z.B. so aus:

CREATE TRIGGER [dbo].[update_zz_98_0]
   ON  [dbo].[zz_98_0]
   AFTER UPDATE
AS 
BEGIN
    SET NOCOUNT ON
    RAISERROR('Dies ist eine Beispiel-Rückmeldung.', 9, 1)
END

Dieses fiktive Beispiel würde bei jedem Speichern eines Containers der Typs 98 mit der Kategorie 0 (zumeist der erste Reiter) eine Meldung zurückgeben.

Der erste Parameter (msg_str) übergibt also eine Meldung (durch das Verwenden lokaler Variablen ließe sich diese auch ergänzen). Den dritten (state) können Sie für Ihre eigenen Zwecke beliebig zwischen 0 und 255 setzen; er wird jedoch von easyLogic selbst derzeit nicht weiter ausgewertet. Für die obigen Unterscheidungen ist der zweite Parameter (severity) interessant:

• 1 - 9 wird von easyLogic als Information weitergegeben. Der Benutzer sieht einen Dialog mit dem Text: Der Speichervorgang war erfolgreich.

  Es wurden jedoch folgende Hinweise übermittelt:

 
  Dies ist eine Beispiel-Rückmeldung.

• 11-18 verhindern das Speichern. Entsprechend anders sieht auch die Meldung beim Benutzer aus: Beim Speichern ist ein Fehler aufgetreten:

 
  Dies ist eine Beispiel-Rückmeldung.

• Ab 19 wird das Speichern verhindert; außerdem wird die Meldung nicht an die meisten Benutzer weitergegeben: Beim Speichern ist ein interner Fehler aufgetreten.

  Bitte wenden Sie sich an den Hersteller.

• 0 und 10 werden nicht an easyLogic durchgeleitet. Sie können diese Schweregrade also intern verwenden.

Sollen bestimmte Benutzer diese Meldungen trotzdem sehen, so muss in StammdatenKonstanten der Punkt ShowInternalSQLErrors für die entsprechende UserID auf 1 gesetzt werden. Dies schließt auch Meldungen vom Datenbank-Server selbst ein; auf diese Weise können Sie also auch technische Probleme durchtesten.

Auch beim fehlgeschlagenen Speichern bleiben die Felder auf dem vorigen Stand (also nicht auf dem Stand der Datenbank), so dass der Anwender eine Chance erhält, eventuelle Eingabefehler zu korrigieren und es erneut zu versuchen.