Stored Procedure mit Problemen

[peter.kinne]

Hallo zusammen,

ich habe zum ersten Mal eine Stored Procedure erstellt, die natürlich nicht klappt. Hier das Umfeld:

Ein RPGLE ermittelt Daten aus der Datenbank. Es kann immer nur ein Satz gefunden werden. Ein VB-Programm ruft die SP auf und bekommt KEINE Daten zurück. Wir bekommen auf der VB-Seite auch keinen Fehler. Die Parameter sind einfach nur leer. Wenn ich das RPGLE auf der AS/400 aufrufe, bekomme ich die richtigen Daten.

Die Stored Procedure habe ich wie folgt erstellt:

CREATE PROCEDURE
LIB/PGMS6100
(INOUT InpUnfAz CHAR ( 9),
INOUT InpEdoOid CHAR ( 15),
INOUT InpEdoKla CHAR ( 5),
INOUT OutEdoTyp CHAR ( 5),
INOUT OutEdoArt CHAR ( 3),
INOUT OutEdoDat CHAR ( 10),
INOUT OutErrMsg CHAR ( 7))
LANGUAGE RPGLE
SPECIFIC LIB/PGMS6100
NOT DETERMINISTIC
NO SQL
EXTERNAL NAME LIB/PGMP6100
PARAMETER STYLE GENERAL

Anweisung CREATE PROCEDURE abgeschlossen.

Hat jemand einen Tipp für mich ????

Gruß

Peter

[Fuerchau]

Jetzt kommts darauf an, wie du in VB die Prozedur aufrufst.
Parameter eines SQL's werden defaultmässig als Inputparameter definiert und können daher nichts zurückgeben.
Du musst daher die Parameter manuell definieren:

dim xConnect as new ADODB.Connection
dim xCmd as new ADODB.Command

with xCmd
.commandtext="call myproc(?, ?, ...)"
.commandtype=adCmdStoredProc
.Parameters.Append .CreateParameter(, adVarChar, adParamInputOutput, 9)
.Parameters.Append .CreateParameter(, adVarChar, adParamInputOutput, 15)
:
Set .ActiveConnection = xConnect
end with

xCmd(0)=Parm1
:

xCmd.execute

[peter.kinne]

Hier die Antwort von unserer PC-Mannschaft:

"Ich habe von Anfang an die Parameter manuell definiert, wie Herr Fuerchau es anmahnt. Liegt also nicht daran, meines Erachtens nach.

Ich kann beim Aufruf auch einfach den Namen der StorProc "LEI.LEIS6100" gegen "LEI. LEISEDBKZ1" (Herr St. StorProc) austauschen und die Daten kommen. Ändere ich es zurück, kommen die Leerstrings."

Kann es sein, dass ich die SP in SQL falsch deklariert habe ???

[Fuerchau]

Wie heißt denn nun die Prozedure ?
Im CREATE PROCEDURE heißt sie doch "LIB/PGMS6100", also muss der Aufruf doch:
call LIB.PGMS6100(?, ?, ?, ?,?, ?, ?) lauten, also für jeden Parameter ein "?" !

[peter.kinne]

Wie heißt denn nun die Prozedure ?
Im CREATE PROCEDURE heißt sie doch "LIB/PGMS6100", also muss der Aufruf doch:
call LIB.PGMS6100(?, ?, ?, ?,?, ?, ?) lauten, also für jeden Parameter ein "?" !

Sorry ! Sie heißt natürlich überall LEIS6100 und das Programm dahinter LEIP6100. Mein erstes Posting war falsch....

[Fuerchau]

Ok !
Aber wie ist denn nun der Aufruf aus VB konkret aus ?
Welcher OLEDB-Treiber wird verwendet ?
Beim IBMDA400 sieht die Welt anders aus als per MSDASQL und CA-ODBC-Treiber !

Beim IBMDASQL gibt es die Unterscheidung zwischen "{CALL PROCEDURE}" und "{{CALL PROGRAM}}" !
Mir scheint, dass eher die Variante CALL PROGRAM verwendet wird als die SQL-Variante, so dass die SQL-Prozedur gar nicht benötigt wird.

[peter.kinne]

Ich habe es an den PC-Mann weitergeleitet, der mit hoffentlich gleich die Antwort liefert.

Bin nur noch bis 14:00 Uhr online.

Vielen Dank,

Peter

[peter.kinne]

Hier die Antwort vom PC-Mann:

Wir setzen den IBMDA400 Treiber ein.

Hier der Code:

strSQL = "LEI.LEIS6100"

' Command Objekt für StoredProcedure konfigurieren

Set cmdDBComm.ActiveConnection = cnnDBConn

cmdDBComm.CommandText = strSQL

cmdDBComm.CommandType = adCmdStoredProc

Debug.Print cmdDBComm.CommandText

Obiges Debug.Print liefert dann folgendes: { call LEI.LEIS6100 }

[Fuerchau]

Dann mach doch folgendes:
{ call LEI.LEIS6100 (?, ?, ?, ?, ...) }
Jedem Fragezeichen wird dann ein Parameter zugeordnet !

[peter.kinne]

Ich muss noch einmal das Thema aufnehmen.

Wir haben zwei System. Auf System_A habe ich zwei Stored Procedures erstellt. Kann ich die nun sichern und auf System_B restoren ? Oder muß ich auf System_B ebenfalls den Befehl "CREATE PPROCEDURE" absetzen.

Gruß

Peter

PS: Die vorherigen Problemen kamen übrigens durch fehlerhafte Treiber. Wir habe nun Treiber der Firma HIT installiert und alles klappt.

[Fuerchau]

Normalerweise reicht ein Save/Restore da das Repository dann upgedatet wird.

PS:
Mit dem IBMDA400 habe ich auch häufig Probleme, deshalb nutze ich grundsätzlich den CA-ODBC-Treiber mit dem MSDASQL, insbesonders da nur mit diesem Commit unterstützt wird.
Ausserdem kostet der nix extra und ist wirklich problemlos !

[peter.kinne]

Vielen Dank.

Ich glaube wir können das Posting nun schließen.

Peter Kinne