View Full Version : API Call mit external SQL Procedure
Zwei Fragen:
1. Hast Du die Stored Procedure auch mal testweise unter STRSQL ausgeführt? Gleiches Ergebnis oder nicht?
2. Könnte irgendwo ein (fehlender) Commit irgendetwas blockieren?
Birgitta
Hallo Frau Hauser,
Den Commit habe ich zunächst im "SQL Prozeduren Ausführen" probiert, jedoch ohne Erfolg.
Unter STRSQL im Green-Screen sehe ich einen Fehler. Das System hat Probleme mit Parameter 4:
Nachrichten-ID . . . . : SQL0469
Nachricht . . . : Attribut IN, OUT oder INOUT für Parameter 4 in Prozedur
CHGPWD in ED14LIB ungültig.
Ursache . . . . : Das Attribut IN, INOUT oder OUT, das für Parameter 4 bei
der Definition der Prozedur angegeben wurde, ist nicht gültig. Der
Parametername ist ERRORCODE. Einer der folgenden Fehler ist aufgetreten:
-- Für einen Parameter OUT kann kein Standardwert angegeben werden.
-- Das Attribut ist mit dem Parameter in der Anweisung CALL nicht
konsistent. Wurde der Parameter als INOUT oder OUT deklariert, muss der
Parameter in der Anweisung CALL als Host-Variable oder globale Variable
angegeben werden.
-- Das Attribut wurde als INOUT oder OUT angegeben und REXX wurde als
Sprache angegeben. Wird REXX angegeben, muss das Attribut IN lauten.
Weitere ...
Wie muss ich den vierten Parameter definieren u. wie hat der CALL auszusehen?
Ich habe es bereits mit IN/INOUT/OUT versucht.
, OUT ErrorCode CHAR(15))
Beim Aufruf habe ich auch entsprechend Kombinationen von 15 * BLANKS, dem Schlüsselwort "default", "null" oder auch "?" auf Gut Glück versucht, alles ähnlich.
Vielleicht liegt das Problem im Aufruf.
Wenn es sich um einen Ausgabe-Parameter handelt, muss dieser als Parameter-Marker also als ? angegeben werden.
Ich weiiß jetzt allerdings nicht, ob STRSQL diese Paramtermarker schon unterstützt.
Birgitta
Errorcode ist eine Struktur und kann nicht als Char definiert werden (Siehe API-Dokumentation)!
Deshalb ist das API auch nicht direkt sondern nur als Wrapper (z.B. ILERPG) verwendbar, da SQL keine Strukturen kennt.
Alternativ kann man auch 8-Byte X'00' übergeben, d.h., keine Fehlermeldung zurückgeben.
Den Parametermarker ? kann man leider (noch) nicht verwenden unserer Version.
Danke Hr. Fürchau, dann bleibt mir der Weg über ein RPGchen wohl nicht erspart :)
Kleine Zwischenstatus. Über das SQL-RPGILE kann ich nun das Kennwort ändern. Einzig für ein VERFALLENES Kennwort habe ich noch meine Probleme.
Da ich ja den ODBC-Kanal mit dem abgelaufenen Kennwort nicht öffnen kann um die externe SQL Prozedur aufrufen.
Die Prozedur ist aber so konzipiert, dass ich nur KennwortAktuell + KennwortNeu übergebe, damit ich auch keine besonderen Rechte für das Programm benötige läuft dann die Kennwortänderung nur für den aktuellen Benutzer, welcher die Verbindung geöffnet hat.
Allerdings habe ich hierzu keine API gefunden. Hat jemand noch eine IDEE?
Das ist ja nur logisch, dass ich mich bei verfallenem Kennwort halt nicht anmelden kann. Da gibts auch kein API.
Alternativ muss man sich mit einem *SECOFR-Profil anmelden (versteckt) und kann dann per CHGUSRPRF ebenso Kennwörter zurücksetzen, Profile aktivieren usw.
Das ist ja nur logisch, dass ich mich bei verfallenem Kennwort halt nicht anmelden kann. Da gibts auch kein API.
Alternativ muss man sich mit einem *SECOFR-Profil anmelden (versteckt) und kann dann per CHGUSRPRF ebenso Kennwörter zurücksetzen, Profile aktivieren usw.
Logisch ist es an sich schon - aber selbst im "alten" Client Access geht dann zumindest ein "Zwangsdialog" auf der mich zwingt das Kennwort zu erneuern oder... PECH gehabt.
Bei uns ist das SECOFR Profile die heilige Kuh - wie kann denn dann gewährleisten nicht X-beliebige User-Kennwörter zu ändern? Im Programm Benutzernamen oder Gruppen validieren?
Das mit dem Zwangsdialog geht aber auch nur, wenn ich die Anmeldung nicht umgehe.
Außerdem kann man weitere Secofr-Profile einrichten.
Aber du hast ja recht, dass ich nicht weiß, welches das Current Profile ist, wenn ich mich mit einem anderen Profil anmelde.
Tja, dann muss man dem User halt sagen, dass er sich vertrauensvoll an seinen Sicherheitsbeauftragten wenden soll.
Ich werde versuchen, dass Programm mit *SECOFR zu kompilieren, dann müsste ich das Recht zum Ändern eines anderen Kennwortes besitzen.
Da die API die Eingabe des vorherigen Kennwortes benötigt kann auch nur ein Benutzerkennwort geändert werden, das ich ohnehin weiß.
Den Fall muss ich also nicht absichern, denn das könnte ich dann auch jetzt schon auf anderen Wegen tun (Greenscreen anmelden --> CHGPWD).