Fetch in externe DS

[JonnyRico]

Nabend,

ich habe da mal ein Problem. Ich war mir eigentlich sicher das das geht und dachte auch ich hätte es schon mal gemacht, aber vielleicht ist es heute auch zu spät. Kann mir jemand sagen wieso ich die Sätze nicht in meine DS "fetchen" kann??

     D $Stamm    E DS                  EXTNAME(DATEI) Qualified

     D Get           PR                  Like($Stamm)

     P Get           B                   Export
     D Get           PI                  Like($Stamm)

     C/Exec SQL Set Option Naming=*SQL
     C/End-Exec
     C/Exec SQL
     C+ Declare StammCur Cursor For
     C+ Select * From DATEI
     C/End-Exec

     C/Exec SQL
     C+ Open StammCur
     C/End-Exec

     C/Exec SQL
     C+ Fetch StammCur Into :$Stamm
     C/End-Exec 

Ich bekomme immer die Meldung $Stamm ist nicht verwendbar oder nicht definiert. Hat jemand einen Tip für mich? Vielen Dank im Voraus.

Gruß

Sascha

[holly]

Hallo,
welches Release benutzt Du denn?
Qualified erst ab V5R3 möglich.

The RPG pre-compiler now includes support for qualified data structure names, nested /Copy directives, and the LikeRec and LikeDS keywords. The precompiler's inability to handle some of the features of the standard compiler like nested /COPYs has been a bane to many. Thankfully, the pre-compiler can now handle some of these features.

For example, using host variables from qualified data structures is just as you'd expect, with the data structure name and subfield name separated by a period:

DdsScreenData DS Qualified
D Item
D DueDate

C/Exec SQL
C+ Select *
C+ From MfgOrders
C+ Where MfgItem=:dsScreenData.Item
C+ And DueDate>=:dsScreenData.DueDate
C/End-Exec

As with the Qualified keyword, the LikeDS and LikeRec keywords generate data structures requiring the use of qualified subfield names. Before V5R3, these qualified names were not allowed to be used by embedded SQL.

Gruß Holger

[Fuerchau]

Beim "Fetch into " gibt es 2 Versionen:

1. Fetch MyCursor into :MyVar
2. Fetch MyCursor for n rows into :MyStru

Strukturen sind nur im Format 2 erlaubt.

[holly]

Beim "Fetch into " gibt es 2 Versionen:

1. Fetch MyCursor into :MyVar
2. Fetch MyCursor for n rows into :MyStru

Strukturen sind nur im Format 2 erlaubt.

Hallo Fürchau
ohne qualified geht auch
1.+2. Fetch MyCursor into :MyStru
mit D MyStru E DS EXTNAME(CONTACT)
selbst in Release 5.2

Gruss Holger

[JonnyRico]

Hi holly,

das ist genau der Punkt Ich habe sonst unter 5.3 gearbeiten und das ganze jetzt auf ein 5.2er System übertragen. Na dann muss das wohl leider ohne QUALIFIED gehen ;(

Danke

Gruß

Sascha

[BenderD]

Hallo,

ich weiß zwar nicht, was du unter welchem Release gemacht hast, aber:
- fetch into :myStructure geht seit 1870, mit und ohne rows Klausel
- qualified ist ihm unter V5R2 schnöde Schnurz
- verschlimmbesssert wurde mit V5R3 (und eventuell auch PTFs, dass SQL Namen jetzt global eindeutig sein müssen, sonst kriegt der Pre Compiler Husten.
- mit SQ dürfen die Namen auch nicht anfangen

Ich deklariere da jetzt separate SQL Work Felder mit preFix ibm, damit ich mir immer merke, warum ich diesen Schwachsinn mache!!!

mfg

Dieter Bender

[B.Hauser]

Hi,

- verschlimmbesssert wurde mit V5R3 (und eventuell auch PTFs, dass SQL Namen jetzt global eindeutig sein müssen, sonst kriegt der Pre Compiler Husten.

Zum Glück wurde das unter Release V5R4 wieder rückgängig gemacht. Die gleiche Host-Variable darf jetzt mehrfach (in verschiedenen Prozeduren) definiert werden. Solange die Host-Variablen die gleiche Definition (Typ und Länge), werden sie anstandslos akzeptiert haben. Haben die Host-Variablen zwar den gleichen Typ, jedoch unterschiedliche Längen, gibt es eine Warnung. Gleiche Host-Variablen jedoch mit unterschiedlicher Definition sind jedoch nicht zulässig.

- mit SQ dürfen die Namen auch nicht anfangen

und auch nicht mit DSN und RDI!

@Dieter: Bist Du eigentlich sicher, dass Du mit IBM als Präfix nicht auch irgenwann auf die Schnauze fällst?
Bisher habe ich noch keinen entsprechenden Kommentar gefunden aber wer weiß! (Dass Hostvariablen nur einmalig definiert werden dürfen, bzw. dass Hostvariablen nicht mit SQ, SQL, DSN und RDI anfangen sollen, war ja auch irgendwo in einem Halbsatz beschrieben!)

Ach, und Qualifizierte Datenstrukuren können nur verwendet werden, wenn in diesen Datenstruktruren keine Unterfelder mit LikeDS definiert sind. D.h. Datenstrukturen mit mehreren Verschachtelungstiefen (z.B. DS.UnterDS.UnterFeld) sind nicht zulässig.

Birgitta

[BenderD]

Hallo,

ob das jetzt besser ist... von modularer Programmierung haben die Verwickler dieses Pre-Compilers immer noch nix begriffen. Variable müssen innerhalb ihres Gültigkeitsbereiches eindeutig sein, was im Rest der Welt gilt, hat keine Bedeutung zu haben. Alles andere zwingt doch dazu die Variablen global mit eigenem Prefix zu definieren.

mfg

Dieter Bender

Hi,



Zum Glück wurde das unter Release V5R4 wieder rückgängig gemacht. Die gleiche Host-Variable darf jetzt mehrfach (in verschiedenen Prozeduren) definiert werden. Solange die Host-Variablen die gleiche Definition (Typ und Länge), werden sie anstandslos akzeptiert haben. Haben die Host-Variablen zwar den gleichen Typ, jedoch unterschiedliche Längen, gibt es eine Warnung. Gleiche Host-Variablen jedoch mit unterschiedlicher Definition sind jedoch nicht zulässig.



und auch nicht mit DSN und RDI!

@Dieter: Bist Du eigentlich sicher, dass Du mit IBM als Präfix nicht auch irgenwann auf die Schnauze fällst?
Bisher habe ich noch keinen entsprechenden Kommentar gefunden aber wer weiß! (Dass Hostvariablen nur einmalig definiert werden dürfen, bzw. dass Hostvariablen nicht mit SQ, SQL, DSN und RDI anfangen sollen, war ja auch irgendwo in einem Halbsatz beschrieben!)

Ach, und Qualifizierte Datenstrukuren können nur verwendet werden, wenn in diesen Datenstruktruren keine Unterfelder mit LikeDS definiert sind. D.h. Datenstrukturen mit mehreren Verschachtelungstiefen (z.B. DS.UnterDS.UnterFeld) sind nicht zulässig.

Birgitta

[B.Hauser]

Hi,

ob das jetzt besser ist... von modularer Programmierung haben die Verwickler dieses Pre-Compilers immer noch nix begriffen. Variable müssen innerhalb ihres Gültigkeitsbereiches eindeutig sein, was im Rest der Welt gilt, hat keine Bedeutung zu haben. Alles andere zwingt doch dazu die Variablen global mit eigenem Prefix zu definieren.

Das liegt halt daran, dass der Pre-Compiler keine Ahnung davon hat, was in der Quelle überhaupt abgeht! Der Pre-Compiler sucht nur nach SQL-Statements, kommentiert die aus und ersetzt die durch API-Aufrufe. Da die Suche nur sequentiell erfolgt, muss auch der DECLARE physisch vor dem OPEN stehen, oder seit Release V5R4 der SET OPTION vor allen anderen SQL-Statements. (Mehr wird der Precompiler wahrscheinlich auch nie leisten!) Es ist immerhin schon ein Vorteil, dass der Pre-Compiler akzeptiert, dass die gleiche Variable mehrfach definiert werden kann.

Außerdem, denke ich ist die Gefahr, dass die gleiche Host-Variable mehrfach, aber unterschiedlich definiert ist, ist relativ gering ist. Wenn ich die Artikel-Nr. oder Bestell-Nr. lokal (mit dem gleichen Namen) definiere, verwende ich eigentlich immer die gleiche Definition. Einmal die Artikel-Nr. 20A und das nächste Mal 15P 0 zu definieren, kann ja nur zum Chaos führen. Ok, es gibt Situationen, in denen man u.U. den gleichen Namen mehrfach mit unterschiedlicher Definition oder Länge verwendet, z.B. irgendeinen String oder ein Rechenfeld, aber doch eher selten.

Ansonsten kann ich mit dieser Rückänderung ganz gut leben.

Birgitta

[BenderD]

das liegt eher daran, dass die Leute, die sich da an diesem Teil probieren, keine Ahnung von Compilern haben. Dasselbe Problem hat jeder Compiler und üblicherweise löst man das dadurch, dass man einmal vorwärts und einmal rückwärts liest und sich dabei eine Symbolliste aufbaut. Das schlimme an der Angelegenheit ist m.E., dass dieses stümperhafte Teil als die Zukunft der Programmierung auf AS400 verkauft wird - da muss man sich nicht wundern, dass selbige nicht gerade rosig aussieht...

mfg

Dieter Bender

Hi,



Das liegt halt daran, dass der Pre-Compiler keine Ahnung davon hat, was in der Quelle überhaupt abgeht! Der Pre-Compiler sucht nur nach SQL-Statements, kommentiert die aus und ersetzt die durch API-Aufrufe. Da die Suche nur sequentiell erfolgt, muss auch der DECLARE physisch vor dem OPEN stehen, oder seit Release V5R4 der SET OPTION vor allen anderen SQL-Statements. (Mehr wird der Precompiler wahrscheinlich auch nie leisten!) Es ist immerhin schon ein Vorteil, dass der Pre-Compiler akzeptiert, dass die gleiche Variable mehrfach definiert werden kann.

Außerdem, denke ich ist die Gefahr, dass die gleiche Host-Variable mehrfach, aber unterschiedlich definiert ist, ist relativ gering ist. Wenn ich die Artikel-Nr. oder Bestell-Nr. lokal (mit dem gleichen Namen) definiere, verwende ich eigentlich immer die gleiche Definition. Einmal die Artikel-Nr. 20A und das nächste Mal 15P 0 zu definieren, kann ja nur zum Chaos führen. Ok, es gibt Situationen, in denen man u.U. den gleichen Namen mehrfach mit unterschiedlicher Definition oder Länge verwendet, z.B. irgendeinen String oder ein Rechenfeld, aber doch eher selten.

Ansonsten kann ich mit dieser Rückänderung ganz gut leben.

Birgitta

[JonnyRico]

Hi,

danke für eure Antworten. Da taucht auch schon das nächte Problem auf. Muss ich das wieder auf IBM-Oldschool-Technik zurückführen???

Es geht um die selbe Quelle. Ich binde per Copy-Strecke den Prozedure-Header aus einem anderen Headerfile ein. SO habe ich es bei V5R3 immer gemacht. Wenn ich das jetzt umwandle, bekomme ich die Meldung. "RPG-Bestimmung nicht in richtiger Reihenfolge". Wenn ich 1:1 aus dem Headerfile die Bestimmungen in meine Quelle kopiere und neu kompiliere, passt es? Was ist da denn wieder los? Habt ihr vielleicht noch mal einen Tip für mich?

Gruß

Sascha

[BenderD]

Hallo,

sind da nested Copy Strecken im Spiel? Sprich: ist in der COPY Strecke eine /COPY Anweisung? das kann das Teil nämlich auch nur manchmal, teils als Bug, teils als Feature, für letzteres gibt es einen extra Work around (Enhancement nennt man sowas heute), die /INCLUDE Anweisung, die macht dasselbe wie /COPY, wird aber vom SQL PreCompiler ignoriert.

mfg

Dieter Bender

Hi,

danke für eure Antworten. Da taucht auch schon das nächte Problem auf. Muss ich das wieder auf IBM-Oldschool-Technik zurückführen???

Es geht um die selbe Quelle. Ich binde per Copy-Strecke den Prozedure-Header aus einem anderen Headerfile ein. SO habe ich es bei V5R3 immer gemacht. Wenn ich das jetzt umwandle, bekomme ich die Meldung. "RPG-Bestimmung nicht in richtiger Reihenfolge". Wenn ich 1:1 aus dem Headerfile die Bestimmungen in meine Quelle kopiere und neu kompiliere, passt es? Was ist da denn wieder los? Habt ihr vielleicht noch mal einen Tip für mich?

Gruß

Sascha