Stored Procedure ignoriert DB-Einstellungen

[Albi]

Hallo,

Ich habe hier ein kleines Problem mit einer StoredProc. In meiner Interbase-DB befinden sich Felder, die nicht NULL sein dürfen.

Wenn ich diese Felder direkt auf der DB ändere bekomme ich Fehlermeldung. Wenn ich jedoch die Felder mit der Procedure einfüge, werden die Einstellungen einfach iknoriert.

Nun habe ich mir ein kleines TestProg gebastelt und kann nun einmal ein Dataset und einmal die StoredProc nehmen. Wenn ich die Daten über die Dataset speicherebekomme eine Fehlermeldung, bei der StoredProc hingegen wird die Einstellung einfach übergangen.

Wie kommt das? Muß ich in der StoredProc noch etwas einstellen oder ist das einfach so und ich muß vorher selber prüfen ob es alles richtig ist?

Hier meine StoredProc:

Code:

REATE PROCEDURE PROCINSERT (
    FNAME VARCHAR (40),
    FPLZ CHAR (5),
    FORT VARCHAR (40))
AS
BEGIN
  Insert into test1 (Name, PLZ, Ort)
  Values (:fName,:fPlz,:fOrt);
  SUSPEND;
END

Und so rufe ich Stored Proc im Programm auf:

Code:

If Form1.RadioButton2.Checked = True Then
  Begin
  With IBSPMain DO
  Begin
    ParamByName('fName').Value:= Edit2.Text;
    ParamByName('fPLZ').Value:= Edit3.Text;
    ParamByName('fOrt').Value:= Edit4.Text;
    ExecProc;
  end;
  IBTMain.Commit;
end;

[edit=sakura] Der Rechtschreibfehler im Titel tat weh Mfg, sakura[/edit]

[Marcel Gascoyne]

Erstmal ist in Deiner Procedure ein Fehler: SUSPEND ist falsch, dies ist nur dazu da Werte Deiner Procedure zurückzuliefern. Du hast aber keine Rückgabeparameter definiert.

Zitat von Albi:

Code:

CREATE PROCEDURE PROCINSERT (
    FNAME VARCHAR (40),
    FPLZ CHAR (5),
    FORT VARCHAR (40))
AS
BEGIN
  Insert into test1 (Name, PLZ, Ort)
  Values (:fName,:fPlz,:fOrt);
  SUSPEND;
END

Hier mal ein Beispiel für Dein Testprogramm mit einem DataSet. Die Procedure hat nun eine Fehlerbehandlung. Die SQL Anweisung für Dein DataSet sollte so aussehen:
select status from procinsert(:fname,:fplz,:fort) Code der Procedure:

Code:

CREATE PROCEDURE PROCINSERT (
    FNAME VARCHAR (40),
    FPLZ CHAR (5),
    FORT VARCHAR (40)
) RETURNS (
  STATUS INTEGER
)
AS
BEGIN
  STATUS = 0;
  Insert into test1 (Name, PLZ, Ort)
  Values (:fName,:fPlz,:fOrt);
  suspend;

  WHEN ANY DO
  BEGIN
    STATUS = 1;
    SUSPEND;
  END
END

Und hier das entsprechende Snipset aus Deinem Testprogramm:

Delphi-Quellcode:

If Form1.RadioButton2.Checked = True Then
Begin
  IBTMain.StartTransaction;
  With MyIBDataSet DO
  Begin
    ParamByName('fName').Value:= Edit2.Text;
    ParamByName('fPLZ').Value:= Edit3.Text;
    ParamByName('fOrt').Value:= Edit4.Text;
    Open;
    
    if FieldByName('STATUS').AsInteger = 0 then
      IBTMain.Commit
    else
    begin
      IBTMain.Rollback;
      ShowMessage('Fehler aufgetreten!');
    end;
  end;
end;

Gruß,
Marcel

[Lemmy]

Hi,

Zitat von Albi:

Und so rufe ich Stored Proc im Programm auf:

Code:

If Form1.RadioButton2.Checked = True Then
  Begin
  With IBSPMain DO
  Begin
    ParamByName('fName').Value:= Edit2.Text;
    ParamByName('fPLZ').Value:= Edit3.Text;
    ParamByName('fOrt').Value:= Edit4.Text;
    ExecProc;
  end;
  IBTMain.Commit;
end;

Hier liegt auch der Fehler begraben! Der Wert von Edit3.Text ist '' und nicht NULL! Da das bei der Zuweisung als String gecastet wird, kommt in der Datenbank auch '' an und nicht NULL!

Warum zum Geier bist Du übrigends auf die kryptische Fehlermeldung des Datenbankservers scharf? Kontrollier doch gleich in der Client-Anwendung, ob alle benötigten Daten eingegeben wurden. Glaubst Du echt, ein unbedarfter User kann mit

Code:

ISC ERROR CODE:335544347

ISC ERROR MESSAGE:
validation error for column PLZ, value "*** null ***"

Statement: insert into Adresse (Name) values ('1');

was anfangen???

Grüße
Lemmy

P.S.: Warum hat Dir übrigends der Thread von gestern nicht gereicht???

[Albi]

Hallo Marcel,

Ich habe jetzt alles so gemacht, wie du geschrieben hast. Aber der Status bleibt immer NULL ob ich da nun ein Feld leer lasse oder nicht.

Liegt es an den Einstellungen der DB oder wie. Den wie schon gesagt, wenn ich das über InsertSQL der DataSet mache, bekomme ich ja ne Fehlermeldung das und das Feld nicht leer sein dürfen.

[Albi]

Zitat von Lemmy:

Da das bei der Zuweisung als String gecastet wird, kommt in der Datenbank auch '' an und nicht NULL!

Das tue ich ja auch, ich überprüfe ja im Proc ob die Felder alle ausgefüllt sind. Mir ist der Unterschied zwischen der StoredProc und der Dataset nur aufgefallen und ich wollt wissen ob es an meiner unfähigkeit liegt oder an etwas anderen.

Wenn ich das also jetzt richtig verstanden habe, sendet die DataSet die Daten so wie sie sind (also nicht gecastet) und die StoredProc wandelt sie bevor es zur DB geschickt wird in den jeweiligen Typ um.

Nun gleich das nächste. Wenn es da solch gravierende Unterschiede zwischen der Dataset und StoredProc gib, welche der beiden verwendet man am besten? Die Insert...,UpdateSQL usw oder StoredProc-Kompo?

[Lemmy]

HI Albi,

ich verwende eigentlich fast immer die TIBDataset (oder vergleichbares), da die TIBStoredProc keinen Int64-Typ unterstützt. Ich habe allerdings keinen Plan von den internen Abläufen, wenn ein IBDataSet mit einem DBEdit verbunden ist und dort die Wertezuweisung abläuft.

Grundsätzlich ist es sinnvoller bei Client/Server-DBs nicht die datensensitiven Komponenten (DBEdit) zu verwenden, sondern "normale" Komponenten und die Wertzuweisung manuell vorzunehmen. Nur so kann die schreibnende Transaktion so kurz wie möglich geöffnet werden und die Warscheinlichkeit eines Deadlocks ist äußerst gering bzw. mach verwendet entsprechende Komponenten die das unterstützen (z.B. die FIBPlus habe eine ReadTransaction und eine WriteTransaction!).

Grüße
Lemmy

[Albi]

Die DBEdit verwende ich ja überhaut nicht. Ich verwende "normale" Edit aber ich habe es bis jetzt immer noch gehandhabt, das ich alles wo ich Daten aufrufe über die DataSet gemacht habe, da ich damit durch die Daten Scrollen kann. Und die TIBStoredProc nur zum speichern und lösen.



Dann werd ich mal

Vielen Dank für die Erklärung. Ich habe es jetzt begriffen.

[Robert_G]

2 Dinge:

• Ich verwende niemals CHAR als Typ für einen Parameter.
  Du kannst dir deine DB mit Constraints nur so vollstopfen, aber Fehler wie dieser machen das alles witzlos.
  ein Char[5] ist entweder NULL oder 5 Stellen lang.
  ParamByName('fPLZ').Value:= Edit3.Text; Durch diese Zeile ist er nicht mehr NULL sondern #32#32#32#32#32. (Deshalb wurde zum Bleistift im .Net FrameWork der Typ DBNull eingeführt. )
  
• Wenn du dein DataSet sowieso nur zum "Scrolling" verwendest, warum nimmst du nicht einfach ein unidirectional Recordset und schiebst es in einen Array.
  Ich weiß jetzt nicht wie es sich mit IB und den IBKompos aus Delphi verhält, aber beim Zugriff auf Oracle mit DOA ist die TOracleQuery die schnellste Komponente (sie kapselt nur einen Ref Cursor -> unidirectional).

[Albi]

Das habe ich noch gar nicht so gesehen, ich bin nur davon ausgegangen das ein CHAR kleiner ist als ein VARCHAR und da eine Postleitzahl eh immer 5 Stellen hat, habe ich mir darüber keine Sorgen gamacht.

Und der Grund warum ich die Dataset nur zum durchblättern der Datensätze nehme war nur dieser, das ich gelesen habe, wie so vieles, das die IBStoredProc einfach schneller ist als die Dataset. Aber mittlerweile denke ich, das eine DataSet wesentlich bequemer ist als die StoredProc.