Embedded SQL: Fetch liefert keine Werte für Date- und Time-Felder

[JotSo]

Hallo,

ich habe mir eine neue Datei per Create Table mit div. Date- und Time-Feldern erzeugt.

Wenn ich jetzt im SQLRPGLE einen Cursor darauf definiere und per Fetch einen Datensatz einlese, stehen mir die Date- und Time-Felder bzw. deren Inhalte nicht zur Verfügung. Alle anderen schon.

Wenn ich mir die Umwandlungsliste anschaue, finde ich die Deklaration der entsprechenden SQL-Variablen, die durch den Precompliner erstellt werden:
D SQL_00019 234 238S 0 WKBORDEROS.P2LFDNR
D SQL_00020 239 248D DATFMT(*ISO) WKBORDEROS.P2EINGDAT
D SQL_00021 249 256T TIMFMT(*ISO) WKBORDEROS.P2EINGZEI
D SQL_00022 257 264T TIMFMT(*ISO) WKBORDEROS.P2EINGZEI
D SQL_00023 265 272T TIMFMT(*ISO) WKBORDEROS.P2SOLLZEI
D SQL_00024 273 274A WKBORDEROS.P2SOLLBST

Beim Füllen werden jetzt aber 20-23 nicht aufgeführt:
C EVAL WKBORDEROS.P2LFDNR = SQL_00019
C EVAL WKBORDEROS.P2SOLLBSTAT = SQL_00024


Hat jemand 'ne Idee, womit dies zusammen hängt?

[B.Hauser]

Normalerweise funktionieren echte Datums- und Zeitfelder sogar besser als numerische Datums- und Zeit-Werte.
Mit der Compilierungsliste lässt sich nicht viel anfangen.
Wie sieht Deine Definition der Ausgabe-Variablen in RPG aus?
Wie sieht Dein DECLARE CURSOR Statement aus?
Wie sieht Dein FETCH Statement aus?

Birgitta

[JotSo]

Hallo Birgitta,

das ist die Datenstruktur, in die ich den Datensatz reinschreibe:
d wkBorderos E DS extname(TBANTR)
d qualified


So sieht der Declare aus:
c/EXEC SQL
c+ declare c_TBANTR cursor
c+ for
c+ select *
c+ from TBANTR
c+ where Prod = 1Prod and
c+ VKONZ =1VKonz and
c+ VBNR =1VBNr and
c+ VDATUM =1VDatum and
c+ EKONZ =1EKonz and
c+ EBNR =1EBNr
c/END-EXEC


UNd so der Fetch:

c/EXEC SQL
c+ fetch c_TBANTR into :wkBorderos :fAnzVar
c/END-EXEC


Aber ich vermute trotzdem, dass es irgendwie schon damit zusammenhängt, dass der Precompiler mir keine Evals generiert. Die sind dann natürlich auch beim Debuggen im RDi nicht da.

gruß

Jürgen

[Fuerchau]

Wenn du die Tabelle per SQL erstellt hast, werden die Felder meist mit ALWNULL erstellt wenn du " not null" beim Create weglässt.
Somit benötigst beim Fetch für jede Variable einen NULL-Anzeiger.
Lässt du diese weg und nur eine Variable hat den NULL-Inhalt bekommst du einen negativen SQL-Code und der Fetch schlägt fehl.
Im Joblog findest du aber auch eine Nachricht "NULL-Anzeiger erforderlich".

[B.Hauser]

Somit benötigst beim Fetch für jede Variable einen NULL-Anzeiger.

Soweit ich das sehe ist eine Indicator Array definiert und übergeben.
Interessant wäre zu wissen, was SQLCODE und/oder SQLSTATE nach dem Fetch zurückliefern.
Ich schätze mal "Feldüberlauf".

Ich auf alle Fälle das (SQL) Datums-Format entweder im Compile-Befehl oder einem SET OPTION Statement am Anfang des Source Codes auf ein Format mit 4-stelligem Datum setzen.
Ansonsten werden die SQL-Hilfvariablen für das Datum mit dem Job-Datums-Format (das meist ein nur 2-stelliges Jahr hat) generiert.
Ich gehe davon aus, dass die eigentlichen Datums-Felder Werte enthalten (z.B. 0001-01-01), die nicht mit einem 2-stelligen Datums-Format abgebildet werden können.

Birgitta

[JotSo]

die Felder wurden mit DATE/TIME NOT NULL bzw. DATE DEFAULT CURRENT_DATE oder TIME DEFAULT CURRENT_TIME erstellt.

Wenn ich die Feldgruppe für die Anzeiger-Variablen fAnzVar weglasse, dann funktionert ist. Dann setzt auch der Precompiler die entsprechenden Eval-Anweisungen.

Kann mir jemand diesen Zusammenhang erklären? Denn ich möchte sie ungern weglassen, da ich tatsächlich Spalten habe, die Null-Werte enthalten können.

[JotSo]

SQLCODE und SQLSTATE sind übrigens beide 0.

[Fuerchau]

Nun, wie ist fAnzVar definiert?
Bei einer DS als Ziel muss fAnzVar als Array definiert sein das mindestens so viele Elemente wie NULL-Felder enthalten muss, mehr ist erlaubt.
Also

D fAnzVar 5I 0 dim(10).

Erkennt der Compiler kein Array, wird die DS als 1 Variable und fAnzVar als 1 Anzeiger angenommen.
Im Listing dürfte dann nur 1 EVAL generiert sein.

[BenderD]

... hast Du mal das komplette listing nach dem zu füllenden Feld durchgescanned? Manche Felder werden nämlich nur bedingt gefüllt und stehen dann hinter den anderen. Und Du solltest mal die nullbyte indicators nach dem fetch prüfen.

D*B

Hallo,

ich habe mir eine neue Datei per Create Table mit div. Date- und Time-Feldern erzeugt.

Wenn ich jetzt im SQLRPGLE einen Cursor darauf definiere und per Fetch einen Datensatz einlese, stehen mir die Date- und Time-Felder bzw. deren Inhalte nicht zur Verfügung. Alle anderen schon.

Wenn ich mir die Umwandlungsliste anschaue, finde ich die Deklaration der entsprechenden SQL-Variablen, die durch den Precompliner erstellt werden:
D SQL_00019 234 238S 0 WKBORDEROS.P2LFDNR
D SQL_00020 239 248D DATFMT(*ISO) WKBORDEROS.P2EINGDAT
D SQL_00021 249 256T TIMFMT(*ISO) WKBORDEROS.P2EINGZEI
D SQL_00022 257 264T TIMFMT(*ISO) WKBORDEROS.P2EINGZEI
D SQL_00023 265 272T TIMFMT(*ISO) WKBORDEROS.P2SOLLZEI
D SQL_00024 273 274A WKBORDEROS.P2SOLLBST

Beim Füllen werden jetzt aber 20-23 nicht aufgeführt:
C EVAL WKBORDEROS.P2LFDNR = SQL_00019
C EVAL WKBORDEROS.P2SOLLBSTAT = SQL_00024


Hat jemand 'ne Idee, womit dies zusammen hängt?

[JotSo]

Hallo zusammen,

das sind sehr gute Fragen von Euch.

Also: für AnzVar habe ich eine globale Feldgruppe definiert:
d gAnzVar S 5I 0 dim(100)


Auf die verweise ich aus meiner internen Funktion raus:
d fAnzVar S like(gAnzVar)
d dim(%elem(gAnzVar))

Dann fehlen definitiv in der Umwandlungsliste die evals für die Datums- und Zeitfelder.

Jetzt kommt's:
wenn ich in meiner internen Funktion die fAnzVar lokal definiere, funktioniert es:
d fAnzVar S 5I 0 dim(100)

Dann habe ich im Listing folgende zusätzliche Anweisung:
C SQL_00054 IFGE 0
C EVAL WKBORDEROS.P2EINGDAT = SQL_00020
C END

Hier scheint der Precompiler wohl mit der Referenzierung auf die globale Variable ein Problem zu haben. Warum sich das aber nur bei Date- und Time-Felder auswirkt, ist mir schleierhaft.