[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Oct 2015
    Beiträge
    109

    Smile SQL Datum nach 2040

    Guten Tag zusammen,

    ich habe auf unserem System (7.1) eine View erstellt.
    Diese baut unter anderem ein Datum zusammen,
    doch sobald ich über das Jahr 2040 hinaus komme, wird das Datum nicht mehr erkannt.
    Hat das evtl damit zu tun: https://de.wikipedia.org/wiki/Jahr-2038-Problem ?
    Und gibt es da eine PTF die das behebt?

    Vielen Dank schon mal

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das hat mit deinem aktuellen SQL-Datumseinstellungen zu tun.
    Per Default steht diese wohl auf *DMY.
    Im STRSQL kannst du das mit F13 anpassen.
    Im Embedded-SQL geht das mit "set option datfmt=*iso;".
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Oct 2015
    Beiträge
    109
    oh noch besser! vielen Dank

  4. #4
    Registriert seit
    Apr 2005
    Beiträge
    385
    Aber warum ist dem so? *DMY ist ja nur eine Formatierung und kein "Kalendar" also sollte es das Jahr 2056 doch auch im Format *DMY geben und nicht nur bis 2038...

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Das Datums-Format wird zumindest in SQL lediglich zur Formatierung des binären Datumswertes (Scaliger No) verwendet.

    Damit ist es SQL egal, ob in der Datei das Geburts-Datum des Firmengründers (26.08.1909) oder das 100-jährige Firmenjubiläum am 01.07.2064 in der Tabelle hinterlegt ist. Beide Datums-Werte sind gültig, werden jedoch sofern im Job ein Format mit einem zweistelligen Jahr verwendet wird, beide nicht angezeigt. Der gültige Bereich für ein Datum mit zwei-stelligem Jahr ist aktuell 1940 bis 2039 - so wurde es nun mal festgelegt.
    Beide Daten können jedoch mit SQL problemlos und korrekt in die Tabelle eingefügt werden, da hier immer mit der Scaliger No gearbeitet wird. Das Job-Datums-Format spielt dabei keine Rolle.

    In RPG ist das anders. RPG konvertiert beim Lesen die Scaliger No IMMER in ein lesbares (alphanumerisches) Datum und konvertiert dieses Datum erst unmittelbar vor dem Zurückschreiben zurück in die Scaliger No. Innerhalb des Programms wird das aufbereitete Datum durchgeschoben. Deshalb sieht man auch im Debugger nie den eigentlichen Binär-Wert.
    Bei einem Datums-Format mit 2-stelligem Datum und einem Datum außerhalb des gültigen Bereichs (1940 - 2039) kommt es in RPG zu einem Abbruch (Feld-Überlauf) da das Jahrhundert in der alphanumerischen Aufbereitung nicht (korrekt) untergebracht werden kann.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    @Birgitta: und wieder falsch!
    Die interne Speicherung als "Scaliger" interessiert SQL herzlich wenig, das ist Sache der Datenbank, aber da wiederhole ich mich nun zum xten Mal!
    Und auch nicht RPG/SQL/COBOL konvertiert den Wert sondern die DB-Runtime.
    Sonst könnte nämlich die alte OPM-Welt nicht native mit den Zeichenketten arbeiten.

    SQL ist die Schnittstelle zwischen Datenbank und Programm und somit braucht es ein Datumsformat.
    Mit diesem Format wird die Scaliger aus dem eingegbenen Datum entwickelt und bei der Ausgabe eben das Datum wiederhergestellt.
    Nur mit dem Datumsformat wird die Ausgabeentscheidung getroffen!
    Diese ist z.B. bei STRSQL mit F13 einzustellen, im OpsNav ist das Default *ISO.
    Bei z.B. *DMY ist das Jahr nun mal 2-Stellig und somit werden nur die Jahre 1940 - 2039 korrekt ausgegeben, bei allem anderen gibts einen NULL-Wert bzw., wenn man Null-Anzeiger verwendet (wie STRSQL) gibts eine -2 = Wert wurde abgeschnitten.
    Bei der Eingabe von Datumswerten (immer als Zeichenketten) gibt es 2 Varianten:
    a) ISO-Format (JJJJ-MM-TT) wird immer akzeptiert
    b) Datum im Jobformat bzw. laut SQL-Options (F13 bei STRSQL)
    Steht das Format nun auf *JOB ist eben nur ein Datum zwischen 1940 und 2039 möglich außer eben bei explizitem *ISO.
    Und somit kommen wir zu embedded SQL:
    SQL generiert für jede Hostvariable eigene SQLnnnn-Variablen (aus welchen Gründen auch immer).
    An Hand der SQL-Option DATFMT werden nun Datumsvariablen mit genau diesem Format erstellt, d.h., jede Datumsvariable bekommt die Erweiterung bzgl. des Datumsformates (RPG4 konnte das sowieso nicht, da musst man Datum als CHAR(10) verarzten).
    Dies gilt sowohl für Parameter-Variablen als auch Ergebnisvariablen. Dies kann man sehr schön in den Compiler-Listings verfolgen.
    Nun schlägt erbarmungslos die Runtime wieder:
    Beim Ausführen von SQL's werden die eigenen Hostvariablen nun in die SQLnnnn kopiert (siehe Listing).
    Hat man sich im RPG für *ISO entschieden und in SQL-Option für *JOB/*DMY kann man nur 1940-2039 verwenden, ansonsten gibt es einen RPG-Runtimefehler mit ungültigem Datumswert.
    Hat man in SQL *ISO/*EUR definiert, gibts keine Probleme.
    Behandelt man im RPG nur *DMY/*JOB ist die Definition für SQL egal.
    Beim Ergebnis von SQL (Select into, Fetch, ...) gibt es nun auch wieder mehrere Fehlermöglichkeiten:
    SQL-Format *JOB/*DMY:
    Bei Datum zwischen 1940-2039 gibts keine Probleme.
    Bei allem anderen gibts 2 Fehler:
    - mit Nullanzeiger => -2 = Wert abgeschnitten
    - Ohne Nullanzeigeer => negativer SQL-Code für ungültige Daten
    SQL-Format *ISO/*EUR:
    Der komplette Bereich wird abgedeckt.
    Allerdings wird ja das Ergebnis est mal in eine SQLnnnn kopiert, die der SQL-Option entspricht.
    Anschließend wird diese in die Hostvariable kopiert und hier entscheidet wieder die RPG-Runtime:
    - Passt der Inhalt zum Format => alles OK
    - Passt der Inhalt nicht => RPG-Laufzeitfehler
    Die RPG-Laufzeit prüft nämlich bei als Datum deklarierten Felder die Gültigkeit des Inhaltes.
    Bei unterschiedlichen Definitionen wird eine Konvertierung durchgeführt, man kann also von *DMY nach *ISO, von *JUL nach *EUR usw. lustig konvertieren so lange der Wert passt.

    Ich hoffe doch nun, dass dies ein für alle Mal klar ist:
    Die interne Speicherung von Datum/Zeit/Zeitmarke interessiert nicht die Bohne, das macht die DB.
    Alle Zugriffe, ob native oder mit SQL, erfolgen als Zeichenkette im gültigen Datum/Zeitformat.
    Mit der so viel beschriebenen "Scaliger" kann ich überhaupt nichts anfangen, die sehe ich allenfals bei einem DMPOBJ einer PF/Table.
    In einem anderen Betrag hatte ich den Wert schon mal geposted:
    "Das Datum in 4-Bytes ist die Anzahl Tage seit dem 1.1.0001 + 1721425."
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Baldur,

    schön, dass Du immer dabei bist wenn ich mit den Herrschaften aus Rochester und Toronto diskutiere.
    Nach Deiner Aussage liegen die alle falsch!

    Auszug aus der aktuellen SQL-Reference:
    The internal representation of a date is a string of 4 bytes that contains an integer.
    The integer (called the Scaliger number) represents the date.
    The length of a DATE column as described in the SQLDA is 6, 8, or 10 bytes,
    depending on which format is used. These are the appropriate lengths for string
    representations for the value.
    Man braucht sich nur mal den Hex-Wert des Datums oder einer Zeitmarke in einer Tabelle anzuschauen.

    ... dass in RPG (mit oder ohne embedded SQL) konvertiert wird und wieder in das interne Format zurückkonvertiert hat mir übrigens Barbara Morris persönlich erzählt.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Dann zeige doch mal bitte wie ich ohne ein Datumsformat zu definieren mit der "Scaliger" arbeiten kann.
    Dies ist doch technisch überhaupt nicht zugelassen.
    Im OPM-RPG gibt es extra Compiler-Anweisungen, dass ein Datum als Zeichenfolge verarbeitet werden darf. Ansonsten ist ein Zugriff nicht möglich.
    Im ILE (RPG/COBOL) wird für jede Datum-Variable eben eine Zeichenkette mit Datumsformat generiert.
    Ich kann diese in eine DS packen und wenn ich diese dann ansehe, sehe ich das Datum in dem angegeben Format als Zeichenkette.
    Ebenso auch, wenn ich eine externe DS definiere.
    In Cobol ist es ebenso. Ich definiere eine Datumvariable, die dann eine Zeichenkette ist.
    Der COPY-DD... generiert ebenso Zeichenketten für Datumsfelder.
    DSPPFM zeigt mir nur Zeichenketten an, und zwar in dem Format, dass ggf. in der Datei definiert ist.

    Also wo bitte finde ich diese blöde Scaliger-No außer in einem DMPOBJ?
    Frag doch diese Damen und Herren aus Rochester mal, wie ich diese Scaliger sichtbar machen kann, das würde mich doch sehr interessieren. Dann lasse ich mich auch gerne eines Besseren belehren.
    Aber so lange das nicht kommt und meine obigen Ausführungen den aktuellen Tatsachen entsprechen, bleibe ich dabei: In der Programmierwelt interressiert die Scaliger nicht sondern ausschließlich das Datumsformat.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. SQL Datum
    By dholtmann in forum NEWSboard Programmierung
    Antworten: 7
    Letzter Beitrag: 03-05-16, 10:35
  2. Antworten: 2
    Letzter Beitrag: 26-05-14, 13:48
  3. Datum berechnen mit CL
    By j.k. in forum NEWSboard Programmierung
    Antworten: 12
    Letzter Beitrag: 15-11-10, 17:31
  4. PWRDWNSYS nach best. Job und IPL zu best. Datum/Uhrzeit
    By cassandra in forum IBM i Hauptforum
    Antworten: 5
    Letzter Beitrag: 30-04-03, 15:39
  5. Keine Journalisierung nach RW nach V5R2
    By csupp in forum IBM i Hauptforum
    Antworten: 5
    Letzter Beitrag: 24-03-03, 17:40

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •