JDBC und UDF

[pkh]

Guten Tag liebe Kollegen,
gestern hatten wir ein kleines Problem mit der Aktualisierung einer auf der iSeries geänderten UDF. Hierbei handelt es sich um eine Function, die Daten in einer Table zurückgibt. Diese Table wurde um 2 Spalte ergänzt. Die Function selbst wurde mit Hilfe einer Textdatei und SQL neu erzeugt. Auf der "grünen" Seite lieferte die Function auch alle Daten inkl. der 2 neuen Spalten ordnungsgemäß zurück. Wurde die Function jedoch in einem SQL innerhalb einer JAVA-Anwendung bzw. im DBVisualizer (bekannt?) aufgerufen, so fehlten die beiden neuen Spalten. Selbst nach Neu-Connection war dies so.
Ganz merkwürdig wurde es, nachdem wir im ON die Function gelöscht haben. SQL-Aufruf sagte dann richtigerweise "Function nicht vorhanden". Dann haben wir die UDF neu erzeugt. Und jetzt kommts: der SQL-Aufruf brachte wieder nur das alte Format.
Was kann denn hier wohl die Ursache sein?
PS: Nach IPL der iSeries ist heue morgen alles bestens. Alle Aufrufe, egal von wo, bringen das neue Format.
Für einen Hinweis, wo wir zu suchen haben, bedanke ich mich schon jetzt.
Beste Grüße
Peter H.

[Fuerchau]

Ggf. schlug hier der Optimizer zu.
Bei einer Funktion, die eine Tabelle zurückgibt, muss diese ja temporär irgendwo incl. ihrer Definition abgelegt werden, damit diese Daten anschließend gelesen werden können.
Temporäre Objekte verschwinden ja nach einem IPL.
Wo nun der Optimizer dieses speichert, entzieht sich mir.
Allerdings deutet der Hinweis, dass native SQL auf der AS/400 die Daten korrekt bekommt, darauf hin, dass es sich rein auf ODBC beschränkt.

ODBC wird über die Hostservices *DATABASE und die PJ's QZDASOINIT verfügbar gemacht.
Da aber PJ's generell wiederverwendet werden, kann es eben auch sein, dass temporäre Objekte erhalten bleiben.

Auch wenn es etwas aufwändiger ist, gibt es eigentlich nur 2 Lösung:
a) Ändert sich die Signatur oder das Ergebnis einer Funktion, so sollte ein neuer Name gewählt werden.
b) Möchte man das nicht ist wohl ein IPL erforderlich. Was auszuprobieren wäre ist ein ENDHOSTSVR *DATABASE, ENDPJ QZDASOINIT, STRHOSTSVR *DATABASE, STRPJ QZDASOINIT.

Lösung a) sollte die favorisierte werden, da sich geändertes Verhalten ggf. massiv auswirkt.
Um sicherzustellen, dass bestehende Programme nicht mit der alten Funktion laufen, die alte Funktion eben löschen und die neue mit neuem Namen erstellen.

Alle betroffenen Programme ggf. halt umwandeln.

Der Vorteil von SQL ist gleichzeitig auch sein Nachteil.
Änderungen sollten immer so gestaltet werden, dass diese bestehende Programme nicht berühren, es sei denn, man möchte einen Crash an den, ggf. vor allem unbekannten Stellen, provozieren.

[pkh]

Hallo,
vielen Dank für die prompte Antwort!!!
Zu den Lösungen:
a) das Verfahren wenden wir eigentlich auch an - in diesem Fall ist nur so, dass das eine neue Funktion ist, die noch nicht im Echtbetrieb läuft und bei der sich eine Änderung ergeben hat
b) tatsächlich nicht so gut, da wir damit ja evtl. auch andere Funktionen lahmlegen und ein IPL über Tag - naja, wir haben leider keine Testmaschine.
Ansonsten sehe ich das mit bisherigem Kenntnisstand auch wie geschildert. Aber vielleicht hat ja jemand anderes noch eine Idee dazu.
Gruß Peter H.