REST-Link aufrufen in CL

[Fuerchau]

Stimmt, als "create table as ..." sollte es auch gehen.
Allerdings sollte man dann den SQL lesen und ausführen, denn im CLP einen SQL zu erstellen ist schon ambitioniert.
Außer, waram auch hier nicht SQL-Scripts?

[B.Hauser]

Stimmt, als "create table as ..." sollte es auch gehen.

View sollte ausreichen!
In der View wird der WebService aufgerufen und auch gleich das zurückgegebene JSON aufgedröselt.
Dann kann man diese mit DCLF definieren und das Ergenbis bzw. die einzelnen Sätze und Spalten nach Belieben verarbeiten.
... das Herumgefuddel mit SQL-Skripten kann man sich dann sparen.
Okay, es ist natürlich zu empfehlen das Skript für das Erstellen der View zu speichern!
... denn was weg ist ist fort und kann auch durch ein Reverse Engineering nicht mehr hergeholt werden!

[Fuerchau]

Bei Views kann man den Erstellbefehl ja noch per DSPFD und sicher dann per API auslesen.

[B.Hauser]

Bei Views kann man den Erstellbefehl ja noch per DSPFD und sicher dann per API auslesen.

1. Würde ich mir (notfalls) den Befehl entweder mit der Stored Procedure GENERATE_SQL oder über ACS - Reverse Engineering holen, anstatt mir über DSPFD die Informationen zusammensuchen zu müssen
2. Wenn die View gelöscht wurde, kann man die Informationen auch mit DSPFD nicht mehr ermitteln. Denn Was weg ist ist fort!

[Fuerchau]

Was weg ist, wird i.d.R. auch nicht mehr gebraucht;-), oder ist das Kunst?.

[Andreas_Prouza]

Alle Sourcen, egal ob PF, LF, RPG, CL, SQL View, SQL Table bis hin zu SQL Prozeduren und Funktionen oder SQL Index, sollten in SRC-PF (oder im IFS) gespeichert werden.

Zumindest wenn man ein Produktives System betreibt wo Stabilität und Nachvollziehbarkeit gefordert sind.
Hat man ein System mit Stages (Development --> Test (UAT) --> Produktion), ist das sowieso Pflicht.

Man kann theoretisch auch aus den Debug Informationen RPG Sourcen generieren, in CL sogar noch einfacher.
Nur weil man etwas auf eine Art machen kann, heißt es nicht, dass es so sinnvoll oder gar empfehlenswert ist.