View Full Version : Verschiedene Datumsformate in RPG
Hallo zusammen!
Ich hänge gerade in RPG an einem sehr seltsamen Datumsproblem! Vielleicht (bzw. so wie ich euch kenne "bestimmt") weiß ja jemand ne Lösung:
In habe in ein RPG-Programm unter anderem 2 Dateien gebunden!
Datei A:
Die eine Datei ist als externe Datenstruktur eingebunden und wird per SQL auf einer anderen AS400 gefüllt.
Ddslbmkk000 E DS extname(lbmkk000)
Prefix(ak)
Datei B:
Die 2. Datei ist eine extern beschriebene Datei auf der lokalen AS400, aus der Daten per READE ausgelesen werden.
ordrhdr01 uf e K disk Prefix(hd)
In beiden Dateien ist ein Datumsfeld vom Typ "DATE" vorhanden und ich möchte nun das Feld aus Datei B in Datei A schieben!
Soweit alles kein Thema! Zumindest eigentlich....
Ich fülle nun das Feld in der Datenstrukter (akAUFDATHS = hdAUFDATHS;) und machen den SQL-INSERT auf Datei A!
Beim SQL fällt das Programm auf die Nase! Meldung: "Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs"
Habe dann mal nen Dump gemacht und mir die Felder angesehen:
Feld aus Datei A: 0001-01-01
Feld aus Datei B: 01.01.0001
Im Header habe ich für das Datumsformat noch folgenden Eintrag gemacht: H DATFMT(*EUR)
Wieso ist das Datumformat in den Dateien unterschiedlich??
Hat das was mit SQL zu tun und ich muss das Feld erst umstellen?
Besten Dank schon mal....
Tobias Heinemann
Hallo zusammen!
Ich hänge gerade in RPG an einem sehr seltsamen Datumsproblem! Vielleicht (bzw. so wie ich euch kenne "bestimmt") weiß ja jemand ne Lösung:
In habe in ein RPG-Programm unter anderem 2 Dateien gebunden!
Datei A:
Die eine Datei ist als externe Datenstruktur eingebunden und wird per SQL auf einer anderen AS400 gefüllt.
Ddslbmkk000 E DS extname(lbmkk000)
Prefix(ak)
Datei B:
Die 2. Datei ist eine extern beschriebene Datei auf der lokalen AS400, aus der Daten per READE ausgelesen werden.
ordrhdr01 uf e K disk Prefix(hd)
In beiden Dateien ist ein Datumsfeld vom Typ "DATE" vorhanden und ich möchte nun das Feld aus Datei B in Datei A schieben!
Soweit alles kein Thema! Zumindest eigentlich....
Ich fülle nun das Feld in der Datenstrukter (akAUFDATHS = hdAUFDATHS;) und machen den SQL-INSERT auf Datei A!
Beim SQL fällt das Programm auf die Nase! Meldung: "Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs"
Habe dann mal nen Dump gemacht und mir die Felder angesehen:
Feld aus Datei A: 0001-01-01
Feld aus Datei B: 01.01.0001
Im Header habe ich für das Datumsformat noch folgenden Eintrag gemacht: H DATFMT(*EUR)
Wieso ist das Datumformat in den Dateien unterschiedlich??
Hat das was mit SQL zu tun und ich muss das Feld erst umstellen?
Besten Dank schon mal....
Tobias Heinemann
Das Problem ist, dass SQL das Datums-Format, das in den D- oder H-Bestimmungen angegeben ist überhaupt nicht interessiert.
Das Datums-Format, das SQL verwendet kann wie folgt gesetzt werden:
1. Im interaktiven SQL über F13 Sitzungs-Attribute ändern
2. Im iSeries Navigator über Verbindung --> JDBC Setup --> Format
3. Im Compile-Befehl CRTSQLxxxI Option DATFMT
4. In Embedded SQL oder SQL/PL über SET OPTION
Ich nehme an, dass der SQL-Befehl im RPG-Programm als embedded SQL abgesetzt wird.
In diesem Fall würde ich empfehlen folgendes SQL-statement einzubinden.
C/EXEC SQL Set Option DatFmt = *ISO
C/END-EXEC
Wichtig ist, dass das SQL-Datums-Format ein 4-stelliges Jahr verarbeitet. Welches ist egal.
Birgitta
Recht schönen Dank für die schnelle Hilfe Brigitta!!
Mein Programm läuft nun auch schon mal durch und führt den SQL-INSERT durch! Ein neues Problem ist dabei allerdings entstanden. Scheinbar habe ich irgendwo noch eine Einstellung falsch....
Wenn ich mir nämlich die Daten per interaktivem SQL in der neu gefüllten Tabelle anschaue, dann wird mein Datumfeld als fehlerhaft angezeigt! In den Sitzungsattributen ist als Datumformat *DMY eingetragen...
Schalte ich das Format auf *ISO oder *EUR, wird das Datum auch richtig angezeigt! Gibt es bei *DMY irgendwie ein Probleme mit dem Lowvalue 0001-01-01??
Das finde ich doch mehr als seltsam.... hat da noch jemand ne Idee!???
Besten Dank noch mal...
Tobias
Recht schönen Dank für die schnelle Hilfe Brigitta!!
Mein Programm läuft nun auch schon mal durch und führt den SQL-INSERT durch! Ein neues Problem ist dabei allerdings entstanden. Scheinbar habe ich irgendwo noch eine Einstellung falsch....
Wenn ich mir nämlich die Daten per interaktivem SQL in der neu gefüllten Tabelle anschaue, dann wird mein Datumfeld als fehlerhaft angezeigt! In den Sitzungsattributen ist als Datumformat *DMY eingetragen...
Schalte ich das Format auf *ISO oder *EUR, wird das Datum auch richtig angezeigt! Gibt es bei *DMY irgendwie ein Probleme mit dem Lowvalue 0001-01-01??
Das finde ich doch mehr als seltsam.... hat da noch jemand ne Idee!???
Besten Dank noch mal...
Tobias
Hallo Tobias,
Vielleicht sollte ich mal etwas weiter ausholen:
Die interne Darstellung eines Datums (also so wie es in einer DB2 UDB-Datei steht) ist 4 byte Binär und stellt einen laufenden Zähler ab Datum x dar.
Was man an der Oberfläche sieht, bzw. was in RPG über DatFMT gesetzt wird, ist nur die Umsetzung diese Datums in eine leserliche Form. (Deshalb ist es auch möglich zwei Datums-Felder mit unterschiedlichem Format zu vergleichen!)
Allerdings gibt es Restriktionen für die Darstellung von Datums-Felder mit 2-stelligem Jahr (z.B. *DMY).
Der gültige Bereich liegt zwischen 01.01.1940 und 31.12.2039.
Der 01.01.0001 ist also ausserhalb dieses Bereichs.
Der *LOVAL bei einem Datum mit 2-stelligem Jahr ist nicht 01.01.0001, sondern 01.01.1940.
Deshalb wird bei der Einstellung *DMY im interaktiven SQL ein ungültiges Datum angezeigt. SQL selber interessiert die Aufbereitung eigentlich nicht, d.h. im interaktiven SQL kannst Du ohne Probleme einen Satz mit Datum 01.01.0001 einfügen.
Beim embedded SQL sieht das etwas anders aus. Die Restriktionen werden von RPG festgelegt, das Format im SQL-Statement von SQL. Die Unstimmigkeiten sind wohl auf gewisse Konversations-Problemen zwischen Toronto (RPG-Compiler-Entwicklung) und Rochester (Datenbank und SQL) zurückzuführen.
Birgitta
@Birgitta
das ist weniger ein Nord-Süd Konflikt, sondern eigentlich nur konsequent:
SQL ist streng typisiert, alles und jedes wird auf Typverträglichkeit überprüft und der 1.1.01 passt nun mal nicht in eine Feld mit einem Typ, der einen Wertebereich vom 1.1.1940 bis 31.12.2039 hat.
RPG kennt intern keinerlei Typprüfung, da kann man jeden Murks in jedes Feld reinquengeln, egal ob das dann stimmt, oder nicht, ich sage da nurmal Feldüberlagerung in Datenstruktur.
mfg
Dieter Bender
Hallo Tobias,
Vielleicht sollte ich mal etwas weiter ausholen:
Die interne Darstellung eines Datums (also so wie es in einer DB2 UDB-Datei steht) ist 4 byte Binär und stellt einen laufenden Zähler ab Datum x dar.
Was man an der Oberfläche sieht, bzw. was in RPG über DatFMT gesetzt wird, ist nur die Umsetzung diese Datums in eine leserliche Form. (Deshalb ist es auch möglich zwei Datums-Felder mit unterschiedlichem Format zu vergleichen!)
Allerdings gibt es Restriktionen für die Darstellung von Datums-Felder mit 2-stelligem Jahr (z.B. *DMY).
Der gültige Bereich liegt zwischen 01.01.1940 und 31.12.2039.
Der 01.01.0001 ist also ausserhalb dieses Bereichs.
Der *LOVAL bei einem Datum mit 2-stelligem Jahr ist nicht 01.01.0001, sondern 01.01.1940.
Deshalb wird bei der Einstellung *DMY im interaktiven SQL ein ungültiges Datum angezeigt. SQL selber interessiert die Aufbereitung eigentlich nicht, d.h. im interaktiven SQL kannst Du ohne Probleme einen Satz mit Datum 01.01.0001 einfügen.
Beim embedded SQL sieht das etwas anders aus. Die Restriktionen werden von RPG festgelegt, das Format im SQL-Statement von SQL. Die Unstimmigkeiten sind wohl auf gewisse Konversations-Problemen zwischen Toronto (RPG-Compiler-Entwicklung) und Rochester (Datenbank und SQL) zurückzuführen.
Birgitta
@Birgitta
SQL ist streng typisiert, alles und jedes wird auf Typverträglichkeit überprüft und der 1.1.01 passt nun mal nicht in eine Feld mit einem Typ, der einen Wertebereich vom 1.1.1940 bis 31.12.2039 hat.
Dieter Bender
@ Dieter,
dann erkläre mir doch mal bitte, warum in folgendem Programm ein Satz ordnungsgemäss in eine Datei geschrieben und angezeigt wird, obwohl das verwendete SQL-Format nur ein 2-stelliges Jahr zulässt.
D MyRPGDate S D DatFmt(*ISO)
C/EXEC SQL Set Option DatFmt = *DMY, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Und jetzt erkläre mir, warum im folgenden Beispiel ein Satz in die Datei geschrieben wird, aber beim SELECT INTO ein Abbruch erfolgt mit RNQ0114 - Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs (C G D F).
(Der einzige Unterschied ist, dass ich die Datums-Formate von SQL und RPG vertauscht habe)
D MyRPGDate S D DatFmt(*DMY)
C/EXEC SQL Set Option DatFmt = *ISO, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
Der Unterschied liegt darin, dass beim Insert eine Konstante verwendet wird und diese ist korrekt, da das Datum der DB ja alles aufnehmen kann.
Probleme gibt es aber beim KONVERTIEREN DB <=> Programm !!!
A ja... sowas habe ich gerade auch noch mal in der RPG-Hilfe gefunden! Macht sinn, dass er dann nen Fehler zeigt!
Aber gut... schönen Dank noch mal für die Hilfe!!
Viele Grüße,
Tobias
Der Unterschied liegt darin, dass beim Insert eine Konstante verwendet wird und diese ist korrekt, da das Datum der DB ja alles aufnehmen kann.
Probleme gibt es aber beim KONVERTIEREN DB <=> Programm !!!
Ok, es gibt einen Abbruch, wenn man eine Host-Variable mit anderem Format verwendet, aber die Fehlermeldung ist RNX0114, also eindeutig ein RPG-Fehler! Ein SQL-Fehler würde einen negativen SQLCOD zurückbringen!
Birgitta
@Birgitta
1. Die Felder in der Datenbank haben ein internes Format, das beim Übergang zu Hostvariablen konvertiert wird.
2. Die SQL Anweisung SET OPTION (oder CRTSQLXXX äquivalent) ist eine Compiletime Anweisung für embedded SQL, bei interaktivem SQL und wirkt auf die Konvertierung zwischen alfa und internem Datumsformat und hat Auswirkungen auf Gültigkeitsbereiche (sliding Window für 2 stellige Jahresangaben).
3. RPG Variablen haben ein Datumsformat, das das Regelwerk steuert wie aus SQL auf (in Wirklichkeit Alfa) Datumsfelder gemappt wird.
4. Literale haben keine Typbindung und RPG versucht das irgendwie hinzukriegen. Für Eingabewerte sind die immer interpretierbaren Formate (Trennzeichen, Reihenfolge, Länge) *ISO *EURO *AMI und *JIS immer gültig.
@ Dieter,
dann erkläre mir doch mal bitte, warum in folgendem Programm ein Satz ordnungsgemäss in eine Datei geschrieben und angezeigt wird, obwohl das verwendete SQL-Format nur ein 2-stelliges Jahr zulässt.
D MyRPGDate S D DatFmt(*ISO)
C/EXEC SQL Set Option DatFmt = *DMY, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
Der Insert klappt, da *ISO Literale immer interpretierbar sind (siehe SQL Reference beim set option), Das auslesen klappt, da das interne Format auf das (passende) Format der Host Variablen gemapt wird.
Und jetzt erkläre mir, warum im folgenden Beispiel ein Satz in die Datei geschrieben wird, aber beim SELECT INTO ein Abbruch erfolgt mit RNQ0114 - Die Jahresangabe eines Datums- oder Zeitmarkenwerts liegt nicht innerhalb des korrekten Bereichs (C G D F).
(Der einzige Unterschied ist, dass ich die Datums-Formate von SQL und RPG vertauscht habe)
D MyRPGDate S D DatFmt(*DMY)
C/EXEC SQL Set Option DatFmt = *ISO, Commit = *None
c/END-EXEC
C/EXEC SQL
C+ Create Table QTEMP/MyDateTable
C+ (MyDate Date Not NULL with Default)
C/END-EXEC
C/EXEC SQL Insert into QTEMP/MyDateTable Values(Date('0001-01-01'))
c/END-EXEC
C/EXEC SQL Select Min(MyDate) into :MyRPGDate from MyDateTable
C/END-EXEC
C MyRPGDate Dsply
C Eval *InLR = *On
Birgitta
Der Insert klappt wieder, weil *ISO Literal, die Konvertierung des internen SQL Formats in die Hostvariable scheitert am zu kleinen Wertebereich der *DMY RPG Variable.
Anmerkung: der SET OPTION Befehl ist in den beiden Beispielen dermatologisch geprüft (den kann man sich bedenkenlos in die Haare schmieren)
mfg
Dieter