View Full Version : SQLRPGLE -> FETCH in Datenstruktur die wiederum eine Datenstruktur enthält
Hallo liebe Forenmitglieder,
ich habe eine Datenstruktur die einer File entspricht also:
DSUPPRSP E DS EXTNAME(UPPRSP) INZ
Leider brauche ich in einem SQL zusätzlich noch die RRN also
Select upprps.*, rrn(upprsp) from upprps where...
Jetzt war mein erster gedanke dass ich einfach eine Datenstruktur erstelle die wiederum eine Datenstruktur enthält also:
SQLDSUPPRSP DS Qualified
XUPPRSP LIKEDS(DSUPPRSP)
RRNO LIKE(X_PXORRN)
Das Ergebnis ist leider dass der SQL-Compiler :
SQL0312 30 920 Position 37 Variable SQLDSUPPRSP nicht definiert oder
nicht verwendbar.
919 C/EXEC SQL
920 C+ FETCH NEXT FROM CSR01 INTO :SQLDSUPPRSP
921 C/END-EXEC
Wenn ich jedoch wieder den Fetch auf DSUPPRSP erstelle gehts, mir fehlt jedoch die RRN.
Jetzt jedes einzelne Feld in den Fetch zu quetschen ist mir persönlich zu doof, da ja auch Änderungen an der Datei jedesmal ein Geraffel werden.
Release V6.1
Viele Grüße
So alles Käse,
die Lösung ist ganz einfach:
- Ich lass die DS wie sie ist und fetch einfach in das nächste Feld (Hier RRN)
dh.:
FETCH NEXT FROM CSR01 INTO :DSUPPRSP ,:RRNO
Danke an den Furchau..das hat er nämlich schon beschrieben, habs nur aufs erste nicht entdeckt :-)
P.S.: Vielleicht wäre die Frage weiterhin für diejenigen interessant die mit einem Fetch 2 Dicke Dateien in eine DS stecken wollen...
Auch wenn 2 dicke Dateien gejoint und ausgegeben werden sollten benötigt man keine einzelne Datenstruktur, sondern kann das Ergebnis durchaus in zwei unabhängige Datenstrukturen ausgeben.
(Embedded) SQL unterstützt keine verschachtelten Datenstrukturen.
... allerdings sollte man mit SQL sich immer gezielt nur das herauspicken, was auch tatsächlich benötigt wird und so zum einen unnötiges "Datengeschaufle" vermeiden und dem Optimizer die Möglichkeit für einen Index Only Access (alle benötigten Informationen sind in den Schlüssel-Feldern der verwendeten Indices hinterlegt, d.h. ein Zugriff auf den eigentlichen Datensatz ist nicht notwendig).
Birgitta
... wer mit select * nicht hinkommt, hat meist ein Problm mit seinem (nicht vorhandenen) View Layer. Wer oft mit Index only access seine Daten kriegt, der hat oft ein Problem mit seinem Datenbank- und Index-Design!
D*B
Wer oft mit Index only access seine Daten kriegt, der hat oft ein Problem mit seinem Datenbank- und Index-Design!
Ich dachte "Index only access" ist was Gutes, weil es den Zugriff auf die Daten beschleunigt !?
Die Betonung liegt ja auch auf "oft"!
Wenn ich i.W. alle meine Daten über Index-Only bekäme, wäre natürlich was falsch.
So extrem, wie es die AS/400 unterstützt, macht es sowieso kaum eine andere DB.
Ich dachte "Index only access" ist was Gutes, weil es den Zugriff auf die Daten beschleunigt !?
... das ist wieder einer der schlauen Gemeinplätze, die sich als dumm herausstellen können:
- ein Index kann größer sein, als die Datei, über die er gebaut ist
- Index only access ist immer read only
- jeder Index kostet maintenance
- in einer normalisierten Datenbank kommt Index only access kaum vor
=> vorrangige Aufgabe ist immer Normalisierung, primary Keys und referential constraints anlegen und ausschließlich über Views zugreifen, dann hat man 90% der Probleme vom Hals.
D*B
andreaspr@aon.at
24-04-14, 10:00
Wir sollten den Ball nicht höher schießen als notwendig!!
Hier war nie die Rede davon, dass eine Vielzahl an Indice erstellt werden sollen um möglichst zwanghaft einen IOA zu erziehlen.
Aber wenn ein Ergebnis schneller vorhanden ist, weil ein EVI, Binary Index, IOA, MQT, gecached wird oder was auch immer für ein Verfahren benützt wird, dann bin ich doch um himmels willen froh darüber!!
Ob die Datenbank ein schlechtes Design hat oder nicht ist dann wieder ein anderes Thema.