StoredProc: Select Into x; x != NULL?!

[user237]

Hallo,

ich habe eine SP erstellt und mir erscheint da etwas mit dem "select into" nicht so ganz logisch... vermutlich besitzt dieses verhalten schon eine logik aber ich seh sie nicht... kann mir einer auf die sprünge helfen?

IB 7.1 & IB 2007!
die Tabelle "tabelle1" enthält keine daten!

und hier die SP:

CREATE PROCEDURE x
RETURNS (
x DOUBLE PRECISION
)
AS
BEGIN
x = 7.4;

SELECT menge FROM tabelle1
INTO x;

SUSPEND;
END


ich bin der meinung, dass wenn keine daten in tabelle1 sind x mit NULL gefüllt werden müsste?!?! leider passiert garnichts und x behält den wert 7.4?!?!?!

hatt jemand eine gute erklärung für dieses verhalten?

grüsse

[Markus Kinzler]

Da der Select kein Ergebnis liefert wird x nicht verändert.

[user237]

Aber wenn mann in der IB console z.b. select * from tabelle1 macht gibts ja dann auch alle spalten mit NULL aus!? dann müsste doch das select into auch NULL geben?!

Schliesslich möchte ich mit into ja befehlen, dass da was reinkommt in die variable...

ist das nur bei IB der fall oder generell bei StoredProcs?

[Markus Kinzler]

In SPs werden Variablen aber nur gesetzt/verändert wenn sie einen Wert haben

[hgdorn]

SELECT menge FROM tabelle1
INTO x;

Müßte es denn nicht auch wenn dann INTO :x (also mit Doppelpunkt davor) lauten?

[user237]

in meinem kleinen beispiel funktioniert beides... (mit x und mit :x)

-wenn eine row in der tabelle1 ist nimmt er den wert an
-wenn zwei oder mehr dann logisch "multiple rows in singleton select"
-wenn keine row dann unlogisch "unverändert"

ja gut... sei's wie's sei... werd es mir einfach merken, dass solche variablen in nem select ohne ergebniss nicht auf NULL sondern den wert behalten, welcher sie vorher hatten...

also gewöhn ich mir x = NULL; vor select into x an.

wenn mich dann mal einer fragt wieso das so ist, sag ich:
- ist so weil ist so, ist so weil war schon immer so, ist so weil ist gut so