Stored Procedure ignoriert DEFAULT

[Hansa]

Hi,

in einer Tabelle habe ich ein Feld als DEFAULT 0 deklariert. Das Einfügen von Daten geschieht mittels Stored Procedure. Die schert sich aber nicht um den Default Wert. Ist er nicht explizit angegeben, dann wird NULL eingetragen.

Ist das normal ? Oder was muß man machen, damit der Default-Wert auf jeden Fall berücksichtigt wird ?

[Marcel Gascoyne]

Was für eine Datenbank verwendest Du denn ? Bei Firebird könnte es so aussehen:

SQL-Code:

create procedure MyProc (
  p_wert integer
)
as
begin
  insert into MyTable (nWert) values (:p_wert);
end

Die Spalte nWert in Deiner Tabelle hat die Einstellung default 0, diese Einstellung
wirkt sich aber nur aus wenn Du keinen Wert übergeben hast, z.b. hast Du im INSERT Statement die Spalte gar nicht angegeben.

Wenn ein Wert für diese Spalte übergeben wird (auch null is ein Wert) greift die Einstellung default nicht. Definier die Spalte mal mit not null, dann sollte die Procedure auch einen Fehler liefern, wenn Du null-Werte einfügen willst.

Gruß,
Marcel

[Hansa]

Zitat von Marcel Gascoyne:

Die Spalte nWert in Deiner Tabelle hat die Einstellung default 0, diese Einstellung wirkt sich aber nur aus wenn Du keinen Wert übergeben hast, z.b. hast Du im INSERT Statement die Spalte gar nicht angegeben.

Genau so siehts aus. 1. Firebird 2. Kein Wert wird angegeben. Trotzdem gehts nicht wie gewünscht. Die NULLEN lassen sich einfügen.

Ich versuche jetzt noch ein DEFAULT 0 NOT NULL zu setzen, aber dann dürfte Fehler kommen wenn der Wert nicht definiert ist. Oder greift dann erst das DEFAULT ???

[urs.liska]

Zitat von Hansa:

Ich versuche jetzt noch ein DEFAULT 0 NOT NULL zu setzen, aber dann dürfte Fehler kommen wenn der Wert nicht definiert ist. Oder greift dann erst das DEFAULT ???

Nein mit Sicherheit nicht. DEFAULT gilt immer dann, wenn kein Wert angegeben wird.

Wie sieht denn Deine INSERT-Procedure aus?
Ist es so, dass in das Feld (von dieser Procedure) nie Werte eingetragen werden oder gibt es mal Werte, mal keine? Im letzteren (wahrscheinlicheren) Fall musst Du klären, was der Procedure übergeben werden. Wird der Procedure (z.B. von einer Delphi-Komponente) nicht ein NULL-Wert übergeben, wenn "keiner" gemeint ist? Wie sollte die Procedure das dann unterscheiden?

Es wäre gut, den Kontext zu kennen, also Tabellenstruktur, INSERT-Procedure, Zugriffsart (Komponenten).

MfG
Urs

[Hansa]

Die SP selbst dürfte wohl klar sein. ID_KUNDE und TAGNR sind DB-Felder. 2 Parameter mit gleichem Namen sind in der SP. In Delphi sieht es dann so aus :

Delphi-Quellcode:

procedure SchreibeDatei (KuNr: string;t: TDate);
begin
//  KuNr := '4';
    if Trim (KuNr) <> '' then
      SP.ParamByName('ID_KUNDE').AsInteger := StrToInt (KuNr);
    SP.ParamByName('TAGNR').AsDate := t;
    SP.ExecProc;
  end;
end;

Der Effekt ist nun, daß selbst wenn KuNr nicht vorhanden ist und eigentlich der Deafault Wert genommen werden müßte, dann steht in der Table NULL drin.

[urs.liska]

Es ist wie ich vermutet habe:
Wenn Du dem SP.Param keinen Wert zuweist, gibt die Komponente NULL an die Stored Procedure weiter und diese trägt das dann natürlich auch ein.

Ich nehme an, in der Tabelle sollen unter ID_KUNDE keine NULLS vorkommen. Dann solltest Du Folgendes tun:
- Feld NOT NULL setzen.
entweder:
- In SchreibeDatei ergänzen

Delphi-Quellcode:

...
if Trim (KuNr) <> '' then
      SP.ParamByName('ID_KUNDE').AsInteger := StrToInt (KuNr)
    else
      SP.ParamByName('ID_KUNDE').AsInteger := 0;

und/oder:
- einen Trigger BEFORE INSERT OR UPDATE definieren mit  if (new.id_kunde is null) then new.id_kunde = 0 Der DEFAULT-Wert könnte dann auch wegbleiben.

Der Trigger wäre auf jeden Fall besser um zu gewährleisten, dass immer alles richtig ist (möglichst wenig Verantwortung in die Applikation auslagern).

Im Übrigen würde ich - falls das nicht im Original ohnehin der Fall ist - prüfen, ob KuNr wirklich einer Integer entspricht und entsprechend reagieren (so wie es dasteht, kommt dann eine Exception mit einer - für den Anwender - vielleicht kryptischen Meldung).

MfG und viel Erfolg
Urs

[Hansa]

Nun denn. Das würde aber bedeuten, daß man die DEFAULT am besten gleich vergisst. Was nützen die denn, wenn man sie definiert und eine SP hebelt alles wieder aus ? Teste es jetzt mit erweitertem Trigger.

P.S.: Daß es ein integer ist, das ist wegen eigener Komponente gewährleistet. Man kann gar keine Buchstaben usw. eingeben.

[urs.liska]

Zitat von Hansa:

Nun denn. Das würde aber bedeuten, daß man die DEFAULT am besten gleich vergisst. Was nützen die denn, wenn man sie definiert und eine SP hebelt alles wieder aus ?

DEFAULT ist dann sinnvoll, wenn
1.) die Daten nicht über eine SP eingefügt werden und
2.) sowohl NULL- als auch DEFAULT-Werte vorkommen dürfen (z.B. ein Fremdschlüssel, der entweder auf einen bestimmten Datensatz zeigt(=irgendeine Zahl) oder auf keinen Datensatz zeigt(=NULL) oder noch nicht definiert/angegeben ist (z.B. -1 für "Noch nicht angegeben").
In einem solchen Fall darf man den Trigger natürlich nicht so schreiben wie ich für Deinen Fall vorgeschlagen habe.

Zitat von Hansa:

Teste es jetzt mit erweitertem Trigger.

P.S.: Daß es ein integer ist, das ist wegen eigener Komponente gewährleistet. Man kann gar keine Buchstaben usw. eingeben.

Aha. Ist dann die Trim-Funktion wirklich nötig? Macht das IntToStr nicht selbst (kann es gerade nicht testen).

MfG
Urs

[Hansa]

Im Original kommt das Trim nicht vor. Das ist komplett aber zu kompliziert, um es hier zu posten. 8)

[Marcel Gascoyne]

Ich würde die Prüfungen direkt in den SP einbauen. Ein Trigger ist zwar eine feine Sache, kostet aber zusätzliche Performance. Wenn Du eh einen SP aufrufst würde ich auch alles in diesem SP machen.

SQL-Code:

create procedure KUNDE_SAVE (
  p_id_kunde integer,
  p_tagnr date
)
as
begin
  if(p_id_kunde is null) then
    p_id_kunde = 0;

  insert into KUNDE (ID,TAG) values (:p_id_kunde,:p_tagnr);
end

Gruß,
Marcel