-
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
-
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;".
-
oh noch besser! vielen Dank
-
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...
-
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: 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."
-
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
-
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.
Similar Threads
-
By dholtmann in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 03-05-16, 09:35
-
By AK1 in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 26-05-14, 12:48
-
By j.k. in forum NEWSboard Programmierung
Antworten: 12
Letzter Beitrag: 15-11-10, 16:31
-
By cassandra in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 30-04-03, 14:39
-
By csupp in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 24-03-03, 16:40
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks