dynamisches SQL

[Armin]

Hallo Wissende,

mit embedded SQL im RPG möchte ich aus dem Artikelstamm Artikel abgreifen, die in einer anderen Datei nicht enthalten sind. Nun ist diese zweite Datei aber jeweils in Kalenderjahre aufgespalten. Ab dem Jahr 2000 hab ich somit 9 Dateien. Mit dyn. SQL hab ich es versucht um mit einer Schleife die Dateinamen variabel einzubinden.
Damit überschreite ich allerdings die max. Länge von 1024 für die Variable beim PREPARE.
Wie kann ich diese Begrenzung umgehen?

[BenderD]

- mit einer view z.B.
ich würde aber erst mal darüber nachdenken ob dieses Design angemessen ist!!!

D*B

Hallo Wissende,

mit embedded SQL im RPG möchte ich aus dem Artikelstamm Artikel abgreifen, die in einer anderen Datei nicht enthalten sind. Nun ist diese zweite Datei aber jeweils in Kalenderjahre aufgespalten. Ab dem Jahr 2000 hab ich somit 9 Dateien. Mit dyn. SQL hab ich es versucht um mit einer Schleife die Dateinamen variabel einzubinden.
Damit überschreite ich allerdings die max. Länge von 1024 für die Variable beim PREPARE.
Wie kann ich diese Begrenzung umgehen?

[Fuerchau]

Die max. Länge eines SQL's ist 32760 !
Du kannst also die Variable entsprechend lang gestalten.

Ich würde aber auch Dieter folgen und eine View über diese 9 Dateien (spater 10, 11, usw) legen:

create view myview
(select .... from jahr1
union all
select ... from jahr2
union all
select ... from jahr3
:
:
)

Dann kannst du mit dieser View joinen und wenn dann weitere Jahre dazukommen, brauchst du nur die View zu ändern.

[B.Hauser]

Hallo,

zunächst 2 Fragen:
1. Welches RPG verwendest Du RPGIII oder RPGIV? (Wobei, wenn ich mich recht erinnere die Grenze bei RPGIII bei 256 Zeichen lag)
2. Unter welchem Release arbeitest Du?

Eigentlich müsste in den letzten Releasen ein String von 32.740 Byte Länge im Prepare-Statement verarbeitet werden können. Prüfe sicherheitshalber, ob Deine Variable nicht nur auf 1024 Zeichen begrenzt ist.

Sollte das nicht helfen ist, müsste ich das Statement sehen, um feststellen zu können, ob es vereinfacht werden kann.
Ansonsten kann man versuchen eine View anzulegen, in der alle Dateien verknüpft werden und diese dann im embedded SQL verwenden (ist so wie so die elegantere Lösung)

Ansonsten könnte noch eine Hilfsdatei generiert werden und mit den entsprechenden Sätzen gefüllt werden.

Oder das SQL-Statement wird in mehrere SQL-Statements gesplittet und das Ergebnis in einer Feldgruppe (oder Array-Datenstruktur) gespeichert und dann weiterverarbeitet.

Birgitta

[BenderD]

@View: ich habe da weniger an eine union view gedacht, die läuft unter DB2/400 meist sehr bescheiden. Mit Views kriegt man die meisten Statements stark vereinfacht (dazu sind diese Dinger nämlich unter anderem da!!!) und damit auch verkürzt.
@temporäre Datei: das macht den Huddel noch größer!
@elegant: diese Daten gehören eigentlich in eine Datei mit einem Feld Jahr (or whatever) und unter einige hunder Millionen Sätzen gibt es keinen Grund das nicht zu tun. Damit eventuell vorhandene Programme, die diesen Huddel mit Jahresdateien verarbeiten keinen Schnupfen kriegen, stellt man auf diese Datei dann n Views, die jeweils ein Jahr rausziehen und so wie bisher heißen.

D*B

[Armin]

Danke erstmal für alle Bemühungen.

Mit der View habt Ihr natürlich Recht. Aber wie Hr. Bender bereits anmerkte, gibts natürlich jede Menge Altprogramme und da ran zu gehen ......

Mein Programm soll ein Reorg werden. Die Performance ist nicht ausschlaggebend. Ich arbeite im Free-RPG unter V5.4. Die Variable kann ich beliebig groß definieren. Der Compiler akzeptiert mehr als 2000Byte. Der Debugger zeigt dann aber nur 1024. Ist hier etwas einstellbar?

[Fuerchau]

Wenn du den STRDBG verwendest, dann einfach "eval myvar : c "

[Armin]

Der strdbg wie auch der Debugger von RDi zeigen 1024 Byte.
Ob im strdbg eval myvar oder eval myvar : c erscheint das gleiche Ergebnis.

Das Lineal endet bei 1024. Es scheint der Compiler hier zu kappen.

Anweisung:
D ARTIKLselect S 2400AVarying

[B.Hauser]

Versuch's mal im Debugger mit einem Substring:

Eval %Substr(MyVAr 1025 100) 

Birgitta

[Fuerchau]

eval ARTIKLselect : c 2400

[Armin]

Fr. Hauser, Hr. Fuerchau und Hr. Bender,

besten Dank für Ihre Unterstützung. Richtig war tatsächlich nur die begrenzte Darstellung in beiden Debuggern.

Mein Problem habe ich jetzt über "union" dynamisch zusammengesetzt. Laufzeit ca. 1/2 Min. und somit absolut zufriedenstellend.

Noch eine Frage:
Lässt sich auch der RDi-Debugger dazu bewegen über die 1024 Stellen hinaus anzuzeigen?

Besten Dank für die prompte Hilfe.

[BenderD]

Hallo,

mit dem RDI Debugger kenne ich mich zwar nicht aus, aber good old Praxis ist bei mir, dass alle im Programm zusammen gebastelten Statements aus der Applikation raus gelogt werden, entweder schnöde mit QMHSNDPM ins Joblog, oder schicker per logger (gibt es auch als Freeware von TR auf der Tools400.de).

D*B

Fr. Hauser, Hr. Fuerchau und Hr. Bender,

besten Dank für Ihre Unterstützung. Richtig war tatsächlich nur die begrenzte Darstellung in beiden Debuggern.

Mein Problem habe ich jetzt über "union" dynamisch zusammengesetzt. Laufzeit ca. 1/2 Min. und somit absolut zufriedenstellend.

Noch eine Frage:
Lässt sich auch der RDi-Debugger dazu bewegen über die 1024 Stellen hinaus anzuzeigen?

Besten Dank für die prompte Hilfe.