Stored Procedure ignoriert DEFAULT

[urs.liska]

Aber:
- mit einem trigger kann die integrität gewährleistet werden, mit einer sp nicht (es könnten jederzeit auf anderem weg datensätze eingetragen werden).
- die performance ist beim einfügen nicht sooo entscheidend.
Urs

[Marcel Gascoyne]

Zitat von urs.liska:

Aber:
- mit einem trigger kann die integrität gewährleistet werden, mit einer sp nicht (es könnten jederzeit auf anderem weg datensätze eingetragen werden).
- die performance ist beim einfügen nicht sooo entscheidend.
Urs

Ist schon richtig, wenn man aber alles über SP's macht und nur EXECUTE PROCEDURE GRANT'ed dann kann kein Anwender manuelle Werte in die Tabelle eintragen.

Gruß,
Marcel

[Hansa]

Wo liegt in diesem Fall der wesentliche Unterschied zwischen Trigger und storede Procedure ? Ein Trigger ist doch auch nichts anderes, als eine spezielle stored Procedure, oder ?

Der Trigger sieht so aus :

SQL-Code:

AS
begin
  IF (NEW.ID IS NULL) THEN            /* Generatorwert lesen und erhöhen */ 
    NEW.ID = GEN_ID(GEN_DATEN_ID, 1);
  IF (NEW.angelegt is NULL) THEN      /* Anlegedatum festhalten */
    NEW.ANGELEGT = current_timestamp;
  IF (NEW.FELD is NULL) THEN          /* wegen stored procedure und default */
    NEW.FELD = 0;
end

FELD ist dabei, das besagte Feld, bei dem es Ärger mit dem Default gab. Wegen des Generators brauche ich den Trigger so oder so. Macht die zusätzliche Zeile Feld = 0 da überhaupt was aus ?

Es gibt noch einen Grund für den Trigger. Normalerweise füge ich Daten über die entsprechende SP ein, aber ich habe auch Fälle, in denen das nicht so ist. Z.B. ein Programm, welches alte Daten in die DB einfügt. Die stored Procedure verwende ich eigentlich hauptsächlich deshalb, um zu gewährleisten, daß automatisch das richtige gemacht wird. Also Insert oder Update, ohne mich drum kümmern zu müssen. Also so :

SQL-Code:

begin
  AENDERN = -1;
  SELECT ID FROM DATEN WHERE (NR= :NR) INTO :AENDERN;
  IF (AENDERN < 0) THEN BEGIN
    INSERT INTO DATEN (NR,...)
           VALUES (:NR,...);
  END
  ELSE BEGIN
    UPDATE DATEN SET MENGE=MENGE+ :MENGE 
    WHERE (NR= :ENR);
  suspend;
end

Natürlich könnte ich die Nullen auch hier abfangen. Also : wer gravierende Einwände gegen den Trigger hat oder für die SP der möge sich melden.

[Marcel Gascoyne]

Bis auf Dein Konstrukt im SP keine Einwände, dort würde ich es wie folgt machen:

SQL-Code:

begin
  IF (NOT EXISTS(SELECT ID FROM DATEN WHERE NR= :NR)) THEN
  BEGIN
    INSERT INTO DATEN (NR,...)
           VALUES (:NR,...);
  END
  ELSE BEGIN
    UPDATE DATEN SET MENGE=MENGE+ :MENGE 
    WHERE (NR= :ENR);
  suspend;
end

Gruß,
Marcel

[urs.liska]

Zitat von Hansa:

Wo liegt in diesem Fall der wesentliche Unterschied zwischen Trigger und storede Procedure ? Ein Trigger ist doch auch nichts anderes, als eine spezielle stored Procedure, oder ?

Der Trigger sieht so aus :

SQL-Code:

AS
begin
  IF (NEW.ID IS NULL) THEN            /* Generatorwert lesen und erhöhen */ 
    NEW.ID = GEN_ID(GEN_DATEN_ID, 1);
  IF (NEW.angelegt is NULL) THEN      /* Anlegedatum festhalten */
    NEW.ANGELEGT = current_timestamp;
  IF (NEW.FELD is NULL) THEN          /* wegen stored procedure und default */
    NEW.FELD = 0;
end

FELD ist dabei, das besagte Feld, bei dem es Ärger mit dem Default gab. Wegen des Generators brauche ich den Trigger so oder so. Macht die zusätzliche Zeile Feld = 0 da überhaupt was aus ?

Nein, ich denke nicht, dass der Trigger hier etwas ausmacht.

Zitat von Hansa:

Es gibt noch einen Grund für den Trigger. Normalerweise füge ich Daten über die entsprechende SP ein, aber ich habe auch Fälle, in denen das nicht so ist. Z.B. ein Programm, welches alte Daten in die DB einfügt.

Genau das ist der Grund, weshalb ich dafür plädiere, die Abfrage im Trigger zu machen. Der Trigger ist die Instanz, die direkt auf Tabellenebene dafür sorgen kann, dass keine unerlaubten Daten eingetragen werden. Alles andere kann durch andere Wege (andere Programme oder sogar Programmierer) umgangen werden.

Grüße
Urs