View Full Version : Fetch in externe DS
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
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
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.
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
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
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
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
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
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
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