Zitat Zitat von B.Hauser Beitrag anzeigen
SQL interessiert das Datums-Format überhaupt nicht, sondern arbeitet immer mit der scaliger no.
Das Datums-Format wird nur dazu verwendet, das Datum lesbar zu machen.
Das Problem ist die Parameter-Übergabe von/an RPG. In RPG wird ein Datum immer in eine alphanumerische Darstellung konvertiert. SQL kann auf der anderen Seite alphanumerische Strings im Format JJJJ-MM-TT, TT.MM.JJJJ und MM/TT/JJJJ als Datum identifizieren und problemlos umsetzen. Wird aus einer SQL-Funktion ein Datum an RPG übergeben, wird dieses in eine alphanumerische Darstellung im *ISO-Format (JJJJ-MM-TT) konvertiert und übergeben.
... und an dieser Stelle kracht RPG.

Was passiert eigentlich, wenn Du die Original-RPG-Funktion, die ein echtes Datum erwartet registrierst, den Datum-Parameter jedoch als CHAR(10) definierst?
Dann überlädst Du die SQL-Funktion und definierst den Datums-Parameter als echtes Datum. In dieser Funktion, konvertierst Du das Datum in eine alphanumerische Darstellung im *Europäischen Format (CHAR(Datum, EUR) und rufst die Origianl-Funktion mit diesem Parameter auf.

Zu Deiner Idee mit dem ISO-Format. Habt Ihr bei den Datums-Feldern im Prototypen ein Datums-Format hinterlegt?
Wenn nein solltet Ihr das tun (DATFMT(*ISO)). Die vorhandenen RPG-Programme sollten dann die Funktion ohne Umstellung des Formats aufrufen können. Die Runtime konvertiert das Datum in das erwartete Format.

Birgitta

Birgitta

Ich habe das eben nochmal durchprobiert:
1. Wenn RPG das Datumsfeld als date(*iso) empfängt und im SQL das Feld als date deklariert ist, klappt es.
2. Wenn RPG das Datum als date(*eur) empfängt und im SQL das Feld als char(10) (oder auch varchar(10) ) deklariert ist, klappt es nicht. Dann kommt der Fehler, dass die SQL-Funktion das Serviceprogramm gar nicht finden kann.

Dieter