Wie behandelt Interbase SELECT INTO abfragen?

[mojo777]

Hallo!
Ich sitze gerade vor so einer aufgabe mit stored procedures folgendes zu realisieren:

Delphi-Quellcode:

SELECT KND_ID FROM TRANSACTION WHERE EINZAHLUNG>1000 INTO :KND_ID;
EXECUTE PROCEDUERE UPDATE_KND_PRIVILEGIEN(:KND_ID);
suspend;

so...
was geschieht da?
wird er mir alle kunden "updaten" bei denen EINZAHLUNG>1000 steht?
Oder macht der das nur mit dem ersten datensatz?
oder passiert gar nichts, weil die procedur UPDATE_KND_PRIVILEGIEN einen Intergerwert erwartet eine Liste dieser aber bekommt?

Kann das jetzt leider noch sehr schlecht testen, weil das sql-programm noch in einer sehr rohen phase ist :-(

Vielen dank für Eure Tipps!

MfG

[jensw_2000]

Die SP wird nur für den ersten Kunden aufgerufen.
Für diese Aufgabe hilft dir nur ein Trigger, oder do musst garantieren, das dein SELECT immer nur einen Datensatz zurückgibt. Das ist aber eher Gefriemel und wenig professionell ...

:hi:

[mojo777]

schade... :-(

gibts da schleifen???

[Hansa]

Zitat:

Zitat von mojo777

Kann das jetzt leider noch sehr schlecht testen, weil das sql-programm noch in einer sehr rohen phase ist :-(

Welches Programm ? :shock: Für so was gibts IBExpert. Da kann man kinderleicht die 2 Zeilen testen. Entweder geht es so nicht, oder es wird der erste bzw. letzte Wert, der der WHERE Klausel entspricht in die Variable gespeichert. Weiß es jetzt selber nicht genau und würde das auch testen, bevor ich groß im Nebel stochere oder umständlich suche. Aber was soll ein Trigger da machen ? Wenn ich mirs nochmal überlege, so wird eine Ergebnismenge gefunden und deshalb wirds mit einem Wert kaum gehen. Wie sollte denn das gehen und wozu überhaupt ?

[mojo777]

@hansa :-)
also mit dem programm meine ich nicht ibexpert :-)
sondern mein programm. der codeausschnitt ist nur ein stark vereinfachtes beispiel.
bei mir hängen viele tabellen von einander ab und wenn sich irgendwo was ändert, sollten die anderen angepasst werden.
ok, habs verstanden. ich werde gleich mal nach dem mittagessen versuchen zu testen :-)

mit triggern ist es so eine sache... die benutze ich sowieso. aber für ergebnismengen....? hä? naja. egal.
hmmm *denk*... joaaaa... ist keine schlechte idee!!!!!
wenn ich

Delphi-Quellcode:

UPDATE TABLE1 SET F1='bla' WHERE <cond>

ausführe, DANN kann wird doch ein trigger nacheinander aufgerufen... also für jeden eintrag einzeln. und so wäre es doch möglich die ergebnismenge zu teilen....
oder? :-D


ist aber krasses gefusche! ;-)

[Hansa]

SQL-Code:

UPDATE TABLE1 SET F1='bla' WHERE F2>1000

Damit werden alle F1-Felder der gesamten Tabelle auf 'bla' gesetzt, sofern F2 > 1000 ! Also Vorsicht !Da geht es aber in erster Linie nicht um eine Menge sondern um die Bedingung > 1000. Und die Bedingung >1000 ist genau festgelegt, ebenso wie der neue Wert 'bla'. Ein Update-Trigger nützt insofern etwas, wenn bei vorliegen einer Bedingung eine Aktion automatisch ausgeführt werden soll. Das geht allerdings eventuell mit einer SP sogar besser. Ich verwende z.B. Update-Trigger um festzuhalten, wann der letzte Zugriff auf einen Datensatz war. Das kann die DB selber erledigen und ich habe meine Ruhe. Alles andere was mit speichern zu tun hat : SP.

[mojo777]

was gibt mir denn der letzte zugriff?
ok ich beschreibe mal mein problem im detail.

ein kunde kauft regelmäßig ein.
dadurch steigt sein wert (menge des bezahlten geldes ;-) )
abhängig von diesem wert wird dem kunden eine gruppe zugewiesen.
z.b. gruppe 2. diese gilt für kunden, die mehr als 1000 eur und weniger als 2000 eur eingezahlt haben.
so. jetzt so so ein benutzer des programms und sagt: wir müssen den bereich der gruppe 2 verschieben. und zwar auf
1500<x<2500
davon wollen ja alle betroffen werden, die in der 2. gruppe vorher gewesen sind.
manche fliegen auch raus und kommen in die 1. gruppe, falls sie <1500 auf dem konto haben.
anhängig von der gruppe und für jeden kunden individuell gibts da noch eine angebotstabelle, in der die rabatte etc gespeichert wind.... da muss sich dann auch einiges ändern, falls die gruppe wandelt.....
soohh...

aber eigentlich ist mir der ansatz jetzt klar!
setze mich dann mal davor. :-D :coder:

vielen DANK!!

:hi:

[imp]

Hallo,

du kannst, wie du schon vermutet hast, Schleifen innerhalb der SP programmieren. Die genaue Syntax weiss ich zwar gerade nicht aber es müsste ungefähr so gehen (genaueres kann dir die Doku liefern):

Code:

FOR SELECT a, b FROM d INTO :value DO
BEGIN
  // Mache was mit :value
END

Schönen Gruß,
Frank

[Hansa]

Nachdem jetzt endlich klar ist, um was es geht (aber nur im Prinzip !) : es liegt ein Denkfehler vor. 8) Folgendes Beispiel soll nur die Vorgehensweise verdeutlichen : Wie speichert man ein Alter ab, um später einem beim 18. Geburtstag ein Geschenk zu schicken ? Man kann es so machen wie mojo das vorhatte und speichert jetzt 17 als Alter und dann geht man hin und muß immer jeden Tag alle Daten durchgehen und prüfen, ob derjenige Geburtstag hat. Ist das der Fall, dann werden die entsprechenden Alter-Werte auf 18 gesetzt und neu abgespeichert. Es gibt da so Sachen wie Normalform u.ä. Die sind nicht umsonst vorhanden, in der Praxis aber meistens nicht zu 100 % umzusetzen. Zumindest bei dem Beispiel mit dem Alter wäre es doch wohl besser das Geburtsdatum zu speichern, aus dem man sich jederzeit das Alter zu einem bestimmten Tag errechnen kann.

Bei der konkreten Sache siehts ähnlich aus. Der Umsatz muß egal bleiben. Der Kunde bleibt bei Umsatz X. Und in zweiter Tabelle steht drin, daß der Umsatz X in Kategorie 2 fällt oder sonstwas. Wird die Grenze von Kategorie 2 verändert, dann fällt der Kunde dementsprechend in andere Kategorie oder auch nicht. Das Feld mit der Gruppe gehört NICHT in die Daten des Kunden !!

P.S.: das hat übrigens noch den großen Nebeneffekt, daß ich mit Änderung eines einzigen Feldes in der Gruppentabelle sämtliche Daten der anderen Tabelle beeinflussen kann.

[jensw_2000]

Zitat:

Zitat von jensw_2000

Die SP wird nur für den ersten Kunden aufgerufen.
Für diese Aufgabe hilft dir nur ein Trigger, oder do musst garantieren, das dein SELECT immer nur einen Datensatz zurückgibt. Das ist aber eher Gefriemel und wenig professionell ...

:hi:

Entschuldige,
das kommt dabei raus wenn man zwischen Tür und Angel noch schnell etwas von sich gibt .. :oops:

Ich meinte nicht Trigger sondern einen Cursor ... :roll:

[mojo777]

@hansa
prinzipiell hast du sicherlich recht. aber ich stand vor der entscheidung das so zu machen und den client einmal die aktuell gültigen angebotstabellen durchzusuchen UND dann noch die ebenen (aka gruppen, oder wie man sie auch bezeichnen kann...) zu überprüfen, oder
so wie ich es gemacht habe:
der client durchsucht nur die angebotstabelle. diese wird jedoch automatisch durch sp mit gültigen rabatten etc aus dem gruppenbereich ergänzt.

hmmm... naja. im anbetracht der etwas komplex gewordenen sp, wäre es vll. doch einfacher den client 2 tabellen zu durchforsten... aber naja. jetzt hab ich wenigstens sp kennen gelernt :-)

vielen dank nochmals!

und ps @jens. dein ausrutscher mit den triggern war zwar nicht so gemaint, aber ich habe das jetzt genau so umgesetzt. :-)
von cursoren in ib hab ich keine ahnung :-(

[Hansa]

Mojo, das ist doch nicht dein Ernst ? :shock: Sphagetticode in Reinkultur. :lol: Datenbank falsch aufgebaut, Denkfehler gleich mit reingehauen und dann noch mit den falschen Methoden und einem zweckentfremdeten Trigger alles so umgebogen bis es aussieht als passe es. So fährt man die Karre an die Wand und man hört irgendwann entnervt auf zu programmieren. Kenne einige authentische Fälle überwiegend aus dem C-Gebiet. Ich würde mal reiflich überlegen, mit so einer Programmierweise überhaupt anzufangen !

[mojo777]

:gruebel:
also ich finde meine lösung elegant. :-D
(ausser das mit den triggern).
aber ich weiss was du meinst. hatte letztens so ein problem in java. :-(
naja. mal gucken. in delphi ist mir soetwas zum glück noch nicht passiert.

[jensw_2000]

Eigentlich ist das garnicht so schwehr ...

Ich benutze IB nicht, und habe auch kein SQL Handbuch dafür hier.
Daher erkläre ich dir das Prinzip mal an Hand der MSSQL Syntax

SQL-Code:

-- du deklarierst einen Cursor für deinen SELECT Befehl
DECLARE CRS CURSOR                                                    
FOR SELECT  SELECT KND_ID FROM TRANSACTION WHERE EINZAHLUNG>1000 

-- dann öffnest du den Cursor       
OPEN CRS                                                              

-- Der Erste Datensatz wird in die Variable @KND_ID gelesen 
FETCH NEXT FROM CRS INTO @KND_ID                                      
                                                                         
-- solange ein Datensatz vorhanden ist ..
WHILE @@FETCH_STATUS = 0                                              
BEGIN

   -- ... führst du deine SP aus ...
   EXECUTE PROCEDUERE UPDATE_KND_PRIVILEGIEN(@KND_ID)                 

 -- ... und holst den nächsten Datensatz.
FETCH NEXT FROM CRS INTO  @KND_ID        

-- Jetzt den Cursor schließen ...
CLOSE CRS                                                             

--  ... und freigeben 
DEALLOCATE CRS

Schöne Grüße,
Jens

[mojo777]

ahh!!! sehr geil!
so gehen also die schleifen! :-)
:-D danke!

[imp]

Oder du benutzt, wie oben bereits beschrieben die FOR SELECT Notation innerhalb der Sored Procedure.

Schönen Gruß,
Frank