ODBC/JDBC Fehlerkontrolle

[Fuerchau]

Dazu müsste ich ja sämtliche UDF's (und das sind einige umschreiben.
Da dies normalerweise ja SQL-Style-UDF's sind kann man ja einen negativen SQLCODE zurückgeben.
Wenn der Kunde bezahlt mach ich das ja gerne.

Es gibt aber auch UDF's (und das sind auch einige) die nun mal nicht von mir sind.

Außerdem habe ich keinen Einfluss auf die ODBC-Anwendungen um denen die zusätzlichen Prüfungen aufs Auge zu drücken.

Ich möchte einfach, dass SQL bei Auftreten von CPF/MCH oder sonstigen Programmabbrüchen (nicht überwachten Nachrichten) nicht einfach weitermacht und so tut als ob nichts passiert wäre und einfach den NULL-Wert als Ergebnis setzt.

Bei embedded SQL gibts häufig was auf die Finger wenn man den NULL-Anzeiger vergisst, wenn man aber einen hat, gibts glaube ich einen negativen Wert von -2 statt -1.
Bei ODBC kann man das aber nicht vergessen da das der Treiber erledigt.
Und alles was im NULL-Anzeiger nicht 0 ist, wird eben zu NULL.

[Robi]

Mein ansatz wäre auch der von MK gewesen.
wenn du teilweise auf die UDF keine Zugriff hast, kannst du nicht eine neue schreiben, die nur die LIB prüft und im Fehlerfall ein 0 zurück gibt. Die SQL's müßten ein zus. Feld zurück geben und ...

Robi

[cbe]

Vielleicht ist eine Prüfung im Exit-Programm bei ODBC-Aufruf möglich?
Ich weiß allerdings nicht, ob man darin die LIB abfragen kann.
Und evtl. ist es auch zu imperformant.

[Fuerchau]

Das Exit-Programm weiß ja nicht, welche UDF denn als nächstes verwendet wird.
Außerdem wird dies ja bei jeder ODBC-Verbindung aufgerufen und darf nciht einfach die LIBL ändern, da die Umgebung ja Anwendungsspezifisch gesetzt wird.
Vielleicht wird ja gerade nur ein Excel-Import, 5250-Dateiübertragung oder ähnliches durchgeführt, wo das Problem keine Rolle spielt.

Es gibt auch einen Exit mit dem man die SQL's analysieren kann.
Man sucht die UDF's, ermittelt über die SYSFuncs/SYSProcs die dazugehörigen Programme.
Dann kann man mittles API-DSPPGMREF prüfen, ob alle Ressourcen in der Libl verfügbar sind, wobei man da nicht unbedingt alles erwischt, da embedded SQL's darüber nicht ermittelt werden können.
Hierfür braucht man dann das API für integrierte oder externe (also verwendete) SQLPKG's (analog PRTSQLINF) um die Ressourcen der dortigen SQL-Statements incl. der UDF's zu prüfen.
Wenn eine Ressource nicht ermittelt werden kann, wird der SQL mit Fehler abgewiesen.

Technisch machbar aber nicht bezahlbar.
Und die Laufzeit einer solchen "Automatik" ist auch nicht zu verachten.
Zumal das Ganze nur in 0,0000001% oder weniger aller Fälle, nähmlich falsche LIBL, sinnvoll währe.

Sonst noch einer eine Idee?
Sonst muss ich wohl oder übel in alle UDF's einen "monitor" einbauen.