User Defined Function in SQL, Datumsübergabe an Serviceprogramm

[dschroeder]

Beide Procedures in einem Serviceprogramm fände ich in diesem Fall auch besser. Geht aber bei uns wegen unseres Toolings (im Moment) nicht.

[dschroeder]

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

[Fuerchau]

Für SQL muss das Feld als DATE definiert sein, da eben an die Prozedur ein DATE übergeben wird!
Genauso muss auch ein Returnwert als DATE definiert sein.
Nun arbeitet halt eine SQL-Function/Prozedur grundsätzlich mit *ISO.

Unabhängig von der H-Bestimmung *EUR lässt sich das Format eines D-Feldes individuell festlegen.
Die Parameter der SQL RPGLE-Prozedur können also mit DATFMT(*ISO) arbeiten. Bei der Übertagung zwischen D-Feldern erfolgt eine Anpassung.

Der Aufruf via SQL ist für alle Sprachen gleich, egal ob STRSQl, embedded SQL, ODBC/JDBC (Java, OpsNav, u.v.m).

Was ich halt meinte, dass man die Aufrufart einer RPG-Prozedur nicht mischen sollte.
Durch "parameter style General" kann ich die Prozedur via SQL oder eben auch native via CALLP verwenden was eben zu verhindern gilt.

Schreibe also eine RPGLE-Prozedur mit *ISO als Datumsformat. Alle RPGLE-Programme mit *EUR als Datumsformat übergeben an SQL ein Datum immer in *ISO!
Schau dir mal nämlich den Spool an. Die SQLnnnn-Variable ist mit DATFMT(*ISO) definiert und bei der Zuweisung von/nach konvertiert die Runtime zwischen *ISO und *EUR.
Deshalb gibt es ja häufig Laufzeitfehler bei falschen Datenformat von der RPG-Runtime und nicht von SQL wenn die Formate nicht konvertierbar sind.

[dschroeder]

Danke für deine Ausführungen. Bisher verfolgen wir das Ziel, ein Serviceprogramm von beiden Umgebungen (SQL und RPG) aufrufen zu können. Wenn wir nicht gerade diese Datumsproblematik haben, klappt das ja auch.

Ich danke nochmals allen für Ihre Antworten.
Dieter.

[BenderD]

Was ich halt meinte, dass man die Aufrufart einer RPG-Prozedur nicht mischen sollte.
Durch "parameter style General" kann ich die Prozedur via SQL oder eben auch native via CALLP verwenden was eben zu verhindern gilt.

... Einspruch: grundsätzlich gilt, dass eine Funktionalität auch nur eine Implementierung hat. Wenn man aus irgendeinem Grund, sei es technische Restriktion (wie hier), oder auch Bequemlichkeit, oder Lesbarkeit mehrere Varianten für die Parameterschnittstelle braucht, so bieten moderne Programmiersprachen (=> RPG ist keine davon) hierfür die Möglichkeit der Überladung.
Bei überladenen Funktionen ist es gängige Praxis, dass es hier nur eine Impelmentierung gibt und die anderen als Adapter fungieren, sprich: Parameterschnittstelle anpassen und die eigentliche Implementierung aufrufen.
Das Problem in diesem Fall ist rein hausgemacht: man hat 2 unsinnige Standards (alle Datumsfelder *EUR und nur eine exportierte Funktion pro SRVPGM) die beide zusammen zu Aufwand führen. Der saubere Weg wäre:
- beide Standards ändern und alle betroffenen Funtionen einfrieren (deprecated), d.h. ist Änderung in der Funktion erforderlich wird die *ISO Schnittstelle im selben Modul zugefügt und die Implementierung dorthin verschoben, die *EUR Schnittstelle wird zum Adapter. Kommt eine Aufruf hinzu, wird die *ISO Variante verwendet und gegebenen Falls eingefügt. Bei neuen Funtionen wird gleich *ISO angelegt.

D*B

[Fuerchau]

Dem kann ich nur zustimmen.
Allerdings finde ich persönlich eben "Parameter style General" eben bedenklich, da man nicht mit NULL und Fehlermeldungen (Diagnose) umgehen kann.
Der "SQL-Aufruf" ist dann wieder zu komplex bzw. lästig. Da kann ich ja dann auch wieder einen Wrapper drumrum stricken.

[BenderD]

... da kommen wir uns schon näher. Bei sauberer Schichtentrennung zwischen Datenbank und Applikation werden SQL Functions nur im View Layer referenziert und da sollten sie keine Fehler zurückwerfen und NULL values lassen sich mit Coalesce rausmaskieren. Also ich bin bisher mit Parameterstyle general immer ausgekommen.
Sollte ich denn Parameterstyle SQL brauchen, dann wird eben wieder eine Procedure mit der erforderlichen Schnittstelle aus demselben Modul exportiert, die die vorhandene RPG procedure in diesem Modul benutzt. Im diskutierten Fall wäre das aber bei sinnigem Standard für Datumsfelder garnicht erforderlich und der Standard gehört geändert (wenn ich merke, dass ich mit dem Auto in eine Sackgasse gefahren bin, dann drehe ich auch sofort und fahre nicht erst bis zum rot/weiß gestreiften Balken).

D*B

[dschroeder]

Ich kann die Argumente nachvollziehen, muss aber sagen, dass die Realität es nicht zulässt, jeden einmal definierten Standard nach Belieben zu ändern. Selbst wenn man erkennt, dass es aus heutiger Sicht besser gewesen wäre, einen anderen Standard zu verwenden. Ein Umstellung aller Programme auf *ISO würde eine Umstellung von mehreren tausend Programmen bedeuten. Selbst wenn wir das mit einem Sourceroboter erledigen würde, wäre eine gewisse Unsicherheit da, ob noch alles funktioniert und ob sich nicht doch irgendwo Algorithmen verstecken, die vom Datumsformat *EUR ausgehen.

Zu Dieters Beispiel mit der Sackgasse: Ich denke, wir sind nicht in einer Sackgasse, sondern eher auf einer unbequemen Nebenstraße und stellen nach 90 Prozent des absolvierten Weges fest, dass es inzwischen eine super ausgebaute Autobahn gibt. Da würde ich dann nicht umdrehen.

Dieter

[BenderD]

... 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]

... 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

[Fuerchau]

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.

[BenderD]

... 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