Dataara mit SQL lesen

[dibe]

Guten Tag,
kann ich mit SQL eine Dtaara lesen?
Eine Funktion oder Procedure habe ich noch nie gemacht!
Hat jemand bitte ein einfaches Beispiel
Besser wäher wenn es 'native' geht.
Danke
Dietlinde Beck

[B.Hauser]

SQL kann NON-Database-Objekte nicht direkt verarbeiten.
Eine Möglichkeit mit SQL auf einen Datenbereich zuzugreifen, besteht darin, z.B. eine RPG-Funktion zu schreiben, die den Datenbereich ausliest und als Rückgabe-Wert ausgibt.
Diese (RPG)Funktion müsste dann mit CREATE FUNCTION als SQL User Defined Function (UDF) registiert werden. Damit könnte der komplette Datenbereich mit SQL über die UDF gelesen werden.

Birgitta

[dibe]

Sowas habe ich befürchtet.
Ich werde versuchen mich in das Thema ein zu arbeiten.
Ein Kollege meinte, das es Probleme mit der Ausführung auf der 'ECHT'-iSeries gibt.
Er glaubt das die Objekte nicht einfach gesichert und restored werden können.
Müssen wir da etwas beachten?
Danke

[Fuerchau]

Nein.
Du schreibst ein RPG/LE-Programm, dass den Inhalt der DTAARA als Parameter zurückgibt.
Erst danach erstellst du die "externe" SQL-Function.
SQL registriert den SQL-Code im Objekt selber, so dass ein Restore auf derselben Maschine die Funktion auch wiederherstellt.
Zu Sicherheit stelle ich die CREATE-Source in eine normale PF-SRC, so dass ich jederzeit durch RUNSQLSTM die Erstellprozedur wiederholen kann.
Leider habe ich es des Öfteren erlebt, dass ein reiner Restore einer externen SQL-Funktion/Prozedur diese nicht ins Repository einträgt.

Der Sicherung steht überhaupt nichts im Weg, da die Programme ja als Objekte vorhanden sind und die Quellen nach Möglichkeit ja auch.
Das SQL-Repository (QSYS2) wird beim SAVSYS ja auch gesichert.
Klar, beim Umzug auf ein neues System muss ich da schon einiges nachholen, z.B. Abarbeiten der obigen PF-SRC.

[dibe]

OK,
also doch!
Ich muß also die Sourceen auch auf die ECHT AS-400 kopieren und dort neu ausführen.
Aber dann brauch ich ja des Objekt nicht zu sichern ?! oder wie ist das zu verstehen?
Danke
Dietlinde Beck

[Fuerchau]

Für externe SQL-Prozeduren hast du 2 "Sourcen".
1. Das Programmobjekt selber
2. den SQL-Befehl "create procedure/function"
Letzteres ist sicherlich als "Quelle" anzusehen.

Das Problem:
Der SQL-Create trägt seinen Code in des Programm-Objekt ein, so dass eine Wiederherstellung im Ernstfall möglich ist.
Zusätzlich steht die Definition natürlich im SQL-Repostory (SQLFunction, SQLProcs, SQLParms) der QSYS2.
Nun wird aber das Programmobjekt aus irgendwelchen Gründen mal neu erstellt (Fehlerbehandlung).
Die SQL-Definition zur Wiederherstellung ist somit verschwunden, da das ersetzte Programm über die QRPLOBJ verschwindet.
Nun müsste eigentlich der "Create-Befehl" wiederholt werden, was allerdings nur mit dem vorherigen Drop funktioniert (aber wer denkt schon daran).
Daher macht es durchaus Sinn, auch den Create-Befehl auf dem Echtsystem aufzuheben, da du den ja beim 1. Mal auf jeden Fall brauchst.