Sql decimal to Date

[BenderD]

@DB: das war früher so, denn ich hatte SQL-Import und ungültige Daten per where ausgefiltert. Im Select hatte ich mich auf den Filter verlassen.
Mit dem Releaseupdate fiel der SQL dann auf die Nase, da doch zuerst der Select und dann der Where ausgeführt wurde. Warum auch immer...

... ich tippe mal auf Pfusch (oder das Problem saß wieder einmal...)

D*B

[Spateneder]

Also:

select ARTNIS, num2date(DATVIS)
from ISBNTBL
where ERDAIS = 20210317

funktioniert fehlerfrei. Aber:

select ARTNIS, num2date(DATVIS)
from ISBNTBL
where ERDAIS = 20210317
and DATVIS > 20211231

bringt den Fehler. Und inzwischen habe ich die banale Ursache gefunden: Einige Datensätze enthalten das "Datum" 20401231. Und leider ist hier (V5R4 ?) am 31.12.2039 das Ende der Zeitrechnung.
Das scheint mir im Moment sowieso recht optimistisch.
Vielen Dank für eure Unterstützung! Das hat mich auf die richtige Spur gebracht.

Einen hab ich noch:
date(digits(DATVIS) concat '000000') liefert den 31.12.2040 als Datumswert.

[BenderD]

... das liegt am verwendeten Datumsformat, aber keineswegs an der where Klausel, selbiger ist es doch egal, welchen Schmutz da jemand in die Datei geschrieben hat. Ich kann immer nur den Kopf schütteln, was es alles noch gibt, ein halbes Jahrhundert nach Verdrängung der Lochkarte...

D*B

[Fuerchau]

Wenn du das Datumformat in der "set options"-Klausel auf ISO und auch im RPGLE-Header auf ISO stellst, hast du mit dem Datum keine Schwierigkeit.
Das hat nur was mit deinem SQL/Programm-Datum als *DMY oder *YMD zu tun.
Die Datenbank kann schon lange das ISO-Format.

Dies gilt auch für deine num2date()-Funktion.

[B.Hauser]

Die Datenbank kann schon lange das ISO-Format.
Dies gilt auch für deine num2date()-Funktion.

Das ist so nicht korrekt! Ein Datum wird grundsätzlich im Scaliger Format, einer laufenden Nr., die auf dem 01.01.4713 v.Chr aufsetzt gespeichert (steht so in der SQL Referenz!). In SQL wird das Datums-Format nur dazu verwendet diese Scaliger No lesbar zu machen. Welches Datums-Format verwendet wird hängt von der Umgebung ab. Ein Datum außerhalb des gültigen Bereichs des Datums-Format (z.B. ein Datum vor 1940 bei einem Datums-Format mit 2-stelligem Jahr) wird einfach nicht angezeigt, jedoch korrekt verarbeitet.

RPG arbeitet anders. Zwar wird auch hier die Scaliger No aus der Datei gelesen, aber direkt beim Lesen in eine alphanumerische Darstellung in entsprechenden Format (D- oder H-Bestimmungen) innerhalb des Programms konvertiert. Innerhalb von RPG wird dieses alphanumerische Format verwendet und erst wieder unmittelbar vor dem Zurückschreiben in die Scaliger No konvertiert. Damit kann es in RPG Probleme mit einem Feld-Überlauf geben, wenn ein 4-stelliges Datum in ein 2-stelliges Datum konvertiert werden soll.
(Diese Information stammt übrigens direkt von Barbara Morris!)

Embedded SQL ist nochmal anders. In embedded SQL wird für jede verwendete Host-Variable eine zusätzliche Hilfs-Variable angelegt. Das Datums-Format für die Hilfs-Variablen wird jedoch weder aus der D- noch H-Bestimmung genommen, sondern aus der Compile-Option (Compile Command oder SET OPTION Statement) und der Default für das Datums-Format im Compile-Befehl ist *JOB (meist 2-stelliges Datums-Format!).
... damit kann es in dem Moment, in dem die Host-Variable in die Hilfs-Variable übertragen wird (wir sind ja an dieser Stelle in RPG) zu einem Fehler/Feldüberlauf kommen.

Langer Rede kurzer Sinn, in embedded SQL Programmen, sollte man dafür sorgen, dass ein Format mit 4-stelligem Jahr (ISO, EUR, USA), wobei ISO die beste Option ist, verwendet wird. Also einfach ein SET OPTION Statement mit DATFMT = *ISO in die Quellen einfügen.

Birgitta

[Fuerchau]

Warum musst du immer auf die internen Speicherung in der Tabelle hinweisen?
Die sehe ich noch nicht mal bei DSPPFM. Die interssiert hier auch nicht.
Auch übernimmt RPG hier keinerlei Umwandlung vor, das macht bereits die unterste Schicht der DB-Funktionen (noch vor SQL).
DSPPFM habe ich schon erwähnt, da kommt das angegebene Datumformat.
Beim Öffnen einer Tabelle/PF als intern beschriebene Datei bekomme ich ebenso direkt das Datum im lesbaren Format.

In SQL oder RPG arbeitet man immer mit einem Datumfeld im angegebene Format (Set option datfmt=xxx), das Format sieht man dann auch in den Umwandlungslisten.
Das selbe gilt für RPGLE, da wird das Datumformat im Header angegeben.

Somit gibts aus Programmierersicht keinen Unterschied zwischen RPG und SQL.
Man muss halt nur nur das korrekt Datumformat anwenden und dies sollte halt nicht unterschiedlich sein. Man kann im RPGLE mit *ISO arbeiten und in der DSPF/PRTF dann mit *EUR. Hier wandelt die Runtime tatsächlich automatisch um.

Im RPGLE kann ich das Format auch explizit bei einem Datumfeld angeben, was der SQL-Precompiler nämlich auch tut. Das sieht man dann bei den entsprechenden SQLnnnn-Feldern.

Definiert man *YMD in den SQL-Optionen, gibts einen SQL-Fehler (SQLCODE, NULL-Anzeiger).
Nimmt man in SQL *ISO und im RPGLE *YMD, gibts einen RPG-Runtimefehler beim
EVAL HOSTDATUM = SQL4711.

Auch bei Zugriffen via ODBC/JDBC bekomme ich ein Feld vom Typ DateTime, dass immer ein Datum enthält (oder NULL).

Und was anderes, nur kürzer, habe ich oben ja auch nicht gesagt.

[BenderD]

Und was anderes, nur kürzer, habe ich oben ja auch nicht gesagt.

... das hat sich aber nicht so schlau angehört.

[Spateneder]

Hallo Birgitta,
vielen Dank! Ich habe beim RUNSQLSTM zum Erstellen der Funktion DATFMT(*ISO) angegeben und jetzt läuft alles reibungslos.

Mathias

[B.Hauser]

@Furchau
Ich finde es toll, dass Du immer alles besser weißt als Barbara Morris (die ja keine Ahnung hat wie ihr compiler und die RPG Runtime funktionieren) und Scott Forstie (der ja auch keine Ahnung von der Architektur der Datenbank) hat.

... und bitte unterlasst zukünftig Eure blöden Bemerkungen. Ich hab' nämlich langsam wirklich keine Lust mehr auch nur noch irgendwas in diesem Forum zu posten.

Birgitta

[Fuerchau]

Das nacht einfach die Erfahrung;-). Und ich habe mir schon früher die Mühe genacht, den generierten MI-Code zu analysieren.
Und daher weiß ich, dass in den Tiefsten Schichten der Datenbank die Funktion QDBGET/QDBPUT aufgerufen werden. Und wenn ich eine Tabelle intern beschrieben einlese, werden mir wie beim DSPPFM de aufbereiteten Datum/Zeit und Zeitmarkenfelder übergeben. Da spielt die RPG-Runtime noch gar keine Rolle.
Zum Vergleich: COBOL nutzt auch bei ILE die nativen Datenpuffer der File-Controlblocks. Und da ist von scaliger Nummern auch nichts zu sehen.

Aber viel wichtiger ist doch, was am Ende rauskommt.
Und da entscheiden die Definitionen der RPG-Felder, die durhch H-Bestimmung und Option-Statement die Formate festlegen.
Was die Datumskonvertierungen angeht, so liegen diese schon früher in den nativen MI-Befehlen, die von der RPG-Runtime halt nur mit verwendet werden.
Deshalb gibts auch MCH- und keine RPG-Fehler.

https://www.ibm.com/docs/en/i/7.4?to...hine-interface
Z.B.:
https://www.ibm.com/docs/en/i/7.4?to...vert-date-cvtd

Somit gibt es mehrere MI-Befehle, die für Konvertierungen und Berechnungen zur Verfügung stehen. Warum sollte sich eine Runtime darüber Gedanken machen und das Rad neu erfinden?
Ich habe sogar einen MI-Compiler geschrieben, mit dem man all die schönen Dinge komfortabel programmierren kann.