Probleme mit SQL UDF in V7

[dschroeder]

Hallo Forum,
wir haben seit heute V7 auf dem System. Es gibt einige Probleme mit unseren SQL-User Defined Functions.

Unsere SQL-Funktionen sind in der Regel so aufgebaut, dass eine SQL-Funktion (z.B. HoleName(..)) eine SQL-Procedure aufruft und diese SQL-Procedure wiederum ein RPGLE-Programm aufruft. Jetzt bekommen wir an diversen Stellen Fehler, weil nicht auf jeder Ebene SQL-Anweisungen zulässig zu sein scheinen. Das Problem scheint in der Schlüsselung "NO SQL", "READS SQL DATA" bzw. "MODIFIES SQL DATA" zu liegen. Bisher haben wir diese Werte wahrscheinlich nicht überall angegeben bzw. eventuell auch nicht korrekt angegeben. Mit V7 führt das jetzt Problemen. Kann mir jemand erklären, was diese Werte genau bedeuten bzw. ob es vielleicht einen Wert gibt, den man immer eintragen kann?

Eine Funktion, die "READS SQL DATA" geschlüsselt hat, bekommt Probleme, wenn die Procedure, die von der Funktion aufgerufen wird, "MODIFIES SQL DATA" beinhaltet. Umgekehrt schein es zu gehen. Für uns ist das unverständlich. Auf der höhereren Ebene kann ich eigentlich gar nicht wissen, wie die Tools der unteren Ebenen arbeiten und ob sie SQL Daten manipulieren. Soll man denn immer MODIFIES SQL DATA reinschreiben, damit man auf der sicheren Seite ist?

Vielen Dank im Voraus,
Dieter

[KM]

Hallo,

schau doch mal ins Handbuch. Da steht folgendes:


CONTAINS SQL: The function does not execute SQL statements that read or modify data.

NO SQL: The function does not execute SQL statements.

READS SQL DATA: The function does not execute SQL statements that modify data.

MODIFIES SQL DATA: The function can execute any SQL statement except those
statements that are not supported in any function.

Normalerweise müsste also immer jedes SQL-Statement ausgeführt werden können, wenn Du "MODIFIES SQL DATA" angibst. Ist halt die Frage, ob das auch wirklich so gewünscht ist.

Gruß,
KM

[dschroeder]

Hallo KM,

vielen Dank für die Antwort. Wir haben das inzwischen auch herausgefunden. Wahrscheinlich werden wir jetzt überall MODIFIES SQL DATA angeben, damit wir auf der sicheren Seite sind. Das finde ich von der Programmstruktur gesehen aber nicht sehr gut. Mein Problem ist: Wenn ich eine SQL-UDF schreibe, die letztendlich (per Procedure) ein RPGLE-Programm aufruft, müsste ich ja wissen, ob das RPGLE-Programm (oder irgendwelche von ihm benutzten Unterprogramme) SQL benutzen oder nicht. Das macht das Programmieren und Pflegen der Programme ganz schön lästig. Denn wenn ich eines dieser RPG-Programm, was zur Zeit vielleicht kein embedded SQL benutzt, später mal modifiziere, sodass es SQL benutzt, schlägt die SQL-Funktion, die das Programm benutzt, fehl. Die Kapselung bzw. Unabhängigkeit der einzelnen Komponenten in der Call-Kette ist damit nicht mehr gegeben.
Aber wahrscheinlich werden wir damit leben müssen.

Nochmals Danke,
Gruß,
Dieter

[Fuerchau]

Wie heißt es immer so schön:
Works as designed.

Wenn ich eine SQL-UDF/Procedure entwickle, so sollte ich andere Proceduren, die selber wiederum SQL-Funktionen darstellen auch per SQL und nicht per CALL aufrufen.

Wird eine Prozedur geändert, so dass sie nun SQL verwendet oder plötzlich SQL-Daten verändert was sie vorher nicht getan hat, so ist das ein Designfehler.
Solche Änderungen bedürfen eigentlich neuer SQL-Funktionen, so dass dies dann kein Problem wäre.

Das ist zugegegben natürlich schwer zu überwachen. Der Einfachheit halber kann man natürlich den allgemeine Weg für alle Prozeduren gehen.

Wenn aber eine Prozedur als READS SQL DATA definiert ist, so darf sie nicht später in MODIFIES SQL DATA geändert werden da dieses ein Designbruch ist und eben genau zu diesen Problemen führt.
Dies gilt natürlich auch für andere Arten von Änderungen.

[KM]

Ich sehe da auch ein großes Problem in der Überwachung bzw. Verwaltung. Wir hatten vor kurzem einen ähnlichen Fall mit folgender Struktur:

1. eine externe stored Procedure (SQLRPG), die ein Resultset zurückgibt, wurde mit "CONTAINS SQL" definiert

2. das SQLRPG-Programm dieser SP ruft ein RPG-Programm auf

3. dieses RPG-Programm ruft eine externe Function auf (SQLRPG), dessen hinterlegtes SQLRPG-Programm einen SQL-Select durchführt.

Zunächst existierten nur die Punkte 1. und 2., was auch problemlos funktionierte. Irgendjemand hat dann Punkt 3. hinzugefügt. Danach wurde festgestellt, dass die SP unter Punkt 1. nicht mehr richtig funktionierte. Erst als man diese auf "READS SQL DATA" umgestellt hat (weil dies ja unter Punkt 3.) benötigt wird, hat alles wieder gepasst.

Da muß man also schon entweder sehr genau aufpassen, was man wo einträgt oder man stellt alles auf "MODIFIES SQL DATA" um.

Gruß,
KM

[B.Hauser]

Ich hatte das gleiche Problem (und noch ein paar andere Kleinigkeiten) vor einiger Zeit und habe mit Kent Milligan darüber gesprochen.

Er meinte das Ganze könnte ein Bug sein, und ich sollte mal einen PMR dafür aufmachen. Ich bin leider noch nicht dazugekommen!

Birgitta