Firebird: SP1 ruft SP2 auf (SP2 enthält For Select)

[hoika]

Hallo #,

kniffliges Problem.

Ich habe eine SP1.
Der wird ein Datum übergeben.

SP2 hat einen fast identischen Code,
nur wird dort statt dem Dateum 'Now' (Current_Date) benutzt.

Es sind selectable SP's.

SQL-Code:

CREATE PROCEDURE SP_GETBASECOSTCENTER2 
RETURNS (
    THEPERSONALID INTEGER,
    THEPERSONALNAME VARCHAR(30),
    THEPERSONALFIRSTNAME VARCHAR(20),
    THECOSTCENTERID INTEGER,
    THECOSTCENTERNO VARCHAR(20),
    THECOSTCENTERNAME VARCHAR(100))
AS
begin
  execute Procedure SP_GETBASECOSTCENTER1('Now')
    Returning_Values
    (THEPERSONALID,THEPERSONALNAME,THEPERSONALFIRSTNAME,
    THECOSTCENTERID,THECOSTCENTERNO,THECOSTCENTERNAME);

  suspend;

end

Das blöde ist jatzt aber.
Es wird nur der 1. Datensatz zurückgegeben (das ist das eine suspend hier),
obwohl in der SP_GETBASECOSTCENTER1 per

For Select do
begin
suspend
end;

mehrere Datensätze zurückgegeben werden.

Ist ja auch klar, weil ich kein Recordset als Return-Parameter habe,
sindern nur einfache Variablen.

Aber was mache ich denn jetzt (unter FB1.5).

Unter FB2x könnte ich temporäre Tabellen benutzen oder jetzt neu Default-Parameter.


Heiko

[mkinzler]

Versuch mal

SQL-Code:

CREATE PROCEDURE SP_GETBASECOSTCENTER2
RETURNS (
    THEPERSONALID INTEGER,
    THEPERSONALNAME VARCHAR(30),
    THEPERSONALFIRSTNAME VARCHAR(20),
    THECOSTCENTERID INTEGER,
    THECOSTCENTERNO VARCHAR(20),
    THECOSTCENTERNAME VARCHAR(100))
AS
begin
  for select 
      * 
  from 
      SP_GETBASECOSTCENTER1('Now')
  into
    :THEPERSONALID,:THEPERSONALNAME,:THEPERSONALFIRSTNAME,
    :THECOSTCENTERID,:THECOSTCENTERNO,:THECOSTCENTERNAME do
  begin
      suspend;
  end
end

[hoika]

Hallo,

ahhh, clever !
Hätte ich selber draufkommen sollen. ;)

For Select * geht zwar nicht,
du musst die Felder angeben.


#Update#
* geht doch. Ist ja sehr verwunderlich.


#Update 2#
Hm, ich benutze zur Optimierung den IB Planalyzer.
Der bringt mir einen Fehler, dass der Plan (Query-Plan) nicht stimmt.
Auch IBExpert zeigt mir nur PLAN an.

Scheint aber ein Problem von FB1.5 zus ein, der 2.1er zeigt den Plan.

Egal: looft.


Danke


Heiko

[Elvis]

Zitat:

Zitat von hoika

#Update#
* geht doch. Ist ja sehr verwunderlich.

Nö, es ist halt vollkommen egal was irgendein Tool behauptet. Nur ob die DB es mag ist interessant.
Anscheinend sind die Aussagen deiner beiden Tools n der Richtung wohl nicht zuverlässig. ;-)

[hoika]

Hallo,

Moment ;)

Ich habe mich nur gewundert, das FB ein Select * genau hier erlaubt.
Sonst ist PSQL doch sehr pingelig, was ja auch gut ist ;).
Stimmt schon, IBExpert prüft SP's ja vorher auch noch ab.
Kann auch sein, dass es in IB6 noch nicht ging.

Ich hätte nicht gedacht, dass das Select * geht,
weil sonst immer die Felder genau definiert werden müssen.
Die Feld-Reihenfolge ist ja per SQL-Standard bei Select* nicht definiert,
aber ich schreibe die ja per Into in eine genau definierte Variablen-Reihenfolge.

Das hatte mich gewundert.


Heiko

[IBExpert]

Zitat:

Zitat von Elvis

Zitat:

Zitat von hoika

#Update#
* geht doch. Ist ja sehr verwunderlich.

Nö, es ist halt vollkommen egal was irgendein Tool behauptet. Nur ob die DB es mag ist interessant.
Anscheinend sind die Aussagen deiner beiden Tools n der Richtung wohl nicht zuverlässig. ;-)

wenn man weiss, wo all diese Tools den Plan herbekommen, dann kann man dazu auch Kommentare
abgeben, wenn man das nicht weiss, wie in diesem Fall offentsichtlich, dann sollte man das
auch nicht kommentieren.

Firebird selbst liefert via API den Plan zu einem Statement zurück, und wenn die Firebird
Version nun mal nichts liefert, dann zeigen die Tools auch nichts an.

[IBExpert]

Zitat:

Zitat von hoika

Hallo,

Ich habe mich nur gewundert, das FB ein Select * genau hier erlaubt.
Sonst ist PSQL doch sehr pingelig, was ja auch gut ist ;).
Stimmt schon, IBExpert prüft SP's ja vorher auch noch ab.
Kann auch sein, dass es in IB6 noch nicht ging.

Ich hätte nicht gedacht, dass das Select * geht,
weil sonst immer die Felder genau definiert werden müssen.
Die Feld-Reihenfolge ist ja per SQL-Standard bei Select* nicht definiert,
aber ich schreibe die ja per Into in eine genau definierte Variablen-Reihenfolge.

Das hatte mich gewundert.


Heiko

select * geht immer wenn zur compilezeit die anzahl der Felder passt, wenn diese sich aber mal
ändern sollte, dann bekommmst du spätestens beim neukompilieren ein Problem, deshalb
immer in Prozeduren die Feldnamen auflösen und auf * verzichten.

[hoika]

Hallo,

Einspruch ;)
Nicht nur die Anzahl der Felder muss stimmen,
auch der Feldtyp.
Ein Select Int_Feld Into :Var_Feld geht nicht.

Ist ja auch egal ;)

Ich habe aus Vorsichtsgründen das Select*
durch Select Feld1, Feld 2 .. ersetzt.

Und es looft ja auch.


Noch mal zum Plan:
Bei FB2.X kommt bei SP1 ein NATURAL (SP2) raus,
bei FB1.5 nix.
Ist wohl ein Bug.


Heiko

[IBExpert]

Zitat:

Zitat von hoika

Hallo,

Einspruch ;)
Nicht nur die Anzahl der Felder muss stimmen,
auch der Feldtyp.
Ein Select Int_Feld Into :Var_Feld geht nicht.

Ist ja auch egal ;)

...

selber einspruch ;)

die Parameter und die Inhalte müssen kompatibel sein, du kannst sehrwohl integer in varchar packen,
auch umgekehrt geht das, wenn im varchar was zu integer kompatibles steht. Firebird ist da extrem
flexibel, führt aber manchmal zu Schlampigkeit, die sich erst beim Endkunden rächt.

[hoika]

Hallo,

re ;)
neh, geht nicht.
Probier es einfach mal aus.
Zumindestens in einer SP klappt das nicht,
es sei denn es wird gecastet.


Hieko