SQL Stored Procedure

[Joe]

Hallo Forum.

Ich habe eine Stored-Procedure mit SQL-Anweisungen erstellt
zum lesen einer Tabelle.

Declare cursor C1 for Select * from Tabelle;
open C1;
Fetch C1 into Feld;
close C1;

Im RPG-Pgm Aufruf in einer Schleife:
DO while irgendwas

EXEC-SQL
call Prozedur
END EXEC
... write Subfile

enddo


Wie muss ich den Fetch definieren, damit ich mehr als 1 Datensatz erhalte?
Wann wird die Prozedur beendet?

Gruss Joe

[Fuerchau]

Das ist so nicht möglich !

Um mehrere Datensätze zurückzugeben musst du die Ergebnistabelle zurückgeben und im RPG selber per Fetch lesen, was in dieser Konstellation nicht sinnvoll scheint.

[Joe]

Danke erstmal.

Heisst das, "Stored Procedures" nur für Einzelsatzverarbeitung
wie z.b. select, insert,update?

Wie realisiere ich denn eine Client-Server Anwendung wenn der
GUI-Client in VARPG oder Delphi geschrieben ist und der Server eine oder keine AS400 ist. Der Zugriff auf die DB soll per SQL erfolgen.

Was wäre denn sinnvoll?


Gruss Joe

[Fuerchau]

Nun, der Zugriff erfolgt ganz normal per SQL.
Dies geschieht sowohl per embedded SQL als auch z.B. per ODBC/JDBC.

Prozeduren sind dann sinnvoll, wenn sie sich 1. leicht in SQL realisieren lassen, 2. ausschließlich Server-Aktionen bedeuten und sehr oft wiederverwendet werden müssen.

Was man früher in Unterprogramme gepackt hat kann man nun (teilweise) in Prozeduren verlagern.

[BenderD]

Hey Joe,

das ist mehr eine Design Frage, als eine technische. Das Kriterium ist hier Schichtentrennung und bei den heutigen (eher verteilten) Applikationen ist es relativ wichtig sowas strikt einzuhalten.
Auf den Datenbankserver gehört alles, was zur Datenbank gehört, also keine Geschäftslogik, die über Constraints hinaus geht.
In die Applikation gehört nichts, was mit Datenbank zu tun hat, also keinesfalls zusammen graben von Daten a la record level access mit read und chain und trulala. Innerhalb der Applikation weiss eigentlich nur die Datenbank Zugriffsschicht, dass es überhaupt eine Datenbank gibt.
Praktisch umgesetzt heisst das:
Alle lesenden Datenbankzugriffe erfolgen über Views und sind relativ elementar (select * from myView where myCondition).
Alle Datenzusammenhänge, wie Auftragskopf- Position, Kunde werden über entsprechende joins (views) abgebildet.
Das einzige komplizierte was jetzt noch überbleibt sind komplexere Transaktioenen beim Schreiben. (Sollbuchung, Habenbuchung, Kundensaldo). Da mag es Kandidaten für stored procedures geben, weil sich sowas in SQL leicht schreiben lässt; aber: sowas nagelt einen an die konkrete Datenbank!
Alles was Datenbankhersteller so erzählen, was an stored procedures so genial ist, hat genau das im Auge.
Einen Randbereich für SP gibt es noch auf der AS400: Einbindung von (vorhandenen) Komponenten; da sins dstored procedures das eleganteste, solange die as400 kein CORBA darf und das fürchte ich, wird so bleiben. Zudem habe ich bisher nur wenig in rpg Anwendungen gesehen, was man Komponente nennen könnte.
Was bei manchem Datenbankdesign schon eher gebraucht wird sind User defined functions, um Logik wieder in die Datenbank zu holen, die in die Applikation gerutscht ist, zum Beispiel: Ermittlung von Rechnungs Adressen, Frachtsätzen, zu faktorierender Kunde bei Konzernen etc.

mfg

Dieter Bender