SQL interessiert das Datums-Format überhaupt nicht und SQL kennt auch kein Datums-Format. SQL arbeitet immer mit dem Binär-Wert/laufenden Zähler (der scaliger no).
Ein Datums-Format wird nur benötigt, um den binären-Datums-Wert lesbar zu machen.
Welches Format dabei verwendet wird, hängt davon ab, welches im aktuellen Job bzw. der aktuellen Verbindung gerade verwendet wird.
Liegt ein Datum außerhalb des anzeigbaren bereichts, wird ++++++ ausgegeben.
Berechnungen, Inserts und Updates werden jedoch korrekt , d.h. mit dem richtigen Datum ausgeführt.

In RPG ist das etwas anders, da RPG die scaliger no immer abh. vom Format der Variablen in eine alphanumrische Darstellung konvertiert und erst unmittelbar vor dem Zurückschreiben wieder in die Scaliger No konvertiert.
Deshalb kann es in RPG vorkommen, das es beim Übertragen von einem Datums-Wert in ein anders Datums-Feld trotz des gleichen Daten-Typs aufgrund von unterschiedlichen Datums-Formaten zu Feldüberläufen kommen kann.

Bei embedded SQL ist es so, dass für jede Host-Variable eine zusätzliche Variable generiert wird. Bei der Definition von Datums-Feldern wird nicht das Datums-Format der Host-Variablen, sondern das Datums-Format, das bei der Compilierung angegeben wurde verwendet. Und der Default-Wert für das Datums-Format ist *JOB.

Der Abbruch erfolgt dann, wenn z.B. eine RPG-Host-Variable mit Datums-Format *ISO, die mit *LOVAL initialiert ist, in die SQL-Variable (mit einem Datums-Format mit nur 2-stelligem Jahr) übertragen wird ... dann macht RPG (und nicht SQL) den Abflug.

Birgitta