View Full Version : Sql decimal to Date
@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...
Die Ausdrücke der Select-Liste werden zuerst ausgeführt, bevor die Where-Klausel geprüft wird.
Das wurde irgenwann zu V6R1 umgestellt.
... das sollte mich wundern, das wäre eine Abkehr vom ANSI Standard.
@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
21-04-21, 16:48
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.
... 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
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.
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
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.
Und was anderes, nur kürzer, habe ich oben ja auch nicht gesagt.
... das hat sich aber nicht so schlau angehört.
Spateneder
28-04-21, 11:56
Hallo Birgitta,
vielen Dank! Ich habe beim RUNSQLSTM zum Erstellen der Funktion DATFMT(*ISO) angegeben und jetzt läuft alles reibungslos.
Mathias