View Full Version : User Defined Function in SQL, Datumsübergabe an Serviceprogramm
... von einer Umstellung aller Programme war nie die Rede!
- es geht um Prgramme, die als stored procedure vernagelt werden und Datumsfelder in der Schnittstelle haben.
- alles was läuft bleibt so wie es ist
- alles was neu kommt wird nach aktualisiertem Standard gemacht
- alles was sowieso zu ändern ist, wird auf schonende Weise angepasst (RPG bietet beide Varianten mit gemeinsamer Implementierung an).
- vorrangig ist, dass ihr die unsinnige Restriktion mit dem ein SRVPGM <=> 1 export überwindet (dafür gibt es auch dutzende von anderen Gründen)
D*B
dschroeder
01-12-14, 11:34
... von einer Umstellung aller Programme war nie die Rede!
- es geht um Prgramme, die als stored procedure vernagelt werden und Datumsfelder in der Schnittstelle haben.
- alles was läuft bleibt so wie es ist
- alles was neu kommt wird nach aktualisiertem Standard gemacht
- alles was sowieso zu ändern ist, wird auf schonende Weise angepasst (RPG bietet beide Varianten mit gemeinsamer Implementierung an).
- vorrangig ist, dass ihr die unsinnige Restriktion mit dem ein SRVPGM <=> 1 export überwindet (dafür gibt es auch dutzende von anderen Gründen)
D*B
OK, dann hatte ich dich falsch verstanden. Mit allem anderen kann ich mich grundsätzlich anfreunden.
Nochmals vielen Dank.
Dieter
Bei dem dann ggf. entstehenden Mischmasch ist es bei den Prototypen (PR) und Interfaces (PI) besonders wichtig, Datumfelder als CONST mit dem korrekten DATFMT zu definieren, damit die Runtime entsprechende Konvertierungen automatisch durchführt.
Problematisch (eigentlich unmöglich) wird es dann, wenn ein Datum in einer Struktur nebst anderen Feldern übergeben wird.
In diesem Fall wir das Datum als CHAR(10) übergeben und die Runtime fällt auf die Nase wenn der Inhalt dem Datumformat nicht entspricht. In solchen Fällen ist dann in der Struktur die Angabe des Formates wichtig.
Die RPG-Runtime kommt mit allem zurecht und konvertiert lustig zwischen den Formate, wenn das Feld angesprochen wird.
... dabei entsteht kein "Mischmasch". Das mit den Prototypen ist noch ein (ausgeklammertes) Problem. Wünschenwert ist eigentlich value, weil nur das sicherstellt, das da nicht drinrumgemalt wird, das kann aber der create function wieder nicht korrekt abbilden.
Wer sogenannte Datenstrukturen als Parameter übergibt, dem ist eh' nicht zu helfen, das sind Binärdaten und man muss den feinsinnigen Humor der Sprachdefiniteure von RPG verstehen, sowas Datenstruktur zu nennen.
D*B
Das Ganze ist doch relativ einfach und mit relativ wenig Aufwand zu handhaben:
Einfach bei den Datums-Feldern in Prototyp und Procedure-Interface DATFMT(*ISO) angeben.
RPG konvertiert die unterschiedlichen Datums-Formate korrekt, d.h. auch wenn in den H-Bestimmungen und/oder D-Bestimmungen das Format *EUR angegeben ist wird das Format im ISO-Format übergeben und anschließend wieder korrekt konvertiert.
Wird die Funktion in SQL als UDF registriert wird das Datum in der alphanumerischen Darstellung eines ISO-Formats übergeben, so wie es RPG erwartet und korrekt weiterverarbeitet.
Birgitta
@Birgitta
Schön, dass du meine Aussagen nur bestätigst:rolleyes:.
andreaspr@aon.at
02-12-14, 08:28
Den Vorschlag hatte Birgitta eigentlich schon auf der ersten Seite gebracht ;)
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
... die spannende Frage ist aber, ob das Nebenwirkungen haben könnte, z.B.: wenn
- der Parameter nicht als CONST oder VALUE deklariert war, also by reference übergeben wird
selbst wenn das ohne recompile der verwendenden Programme durchgeht, würde ich mich da nicht drauf verlassen wollen, ob das nach jedem Release Wechsel noch funzt, es gab da so einiges an verschärften Prüfungen, wo dann Programme unter V7R1 ...
D*B