IBMDA400 OLEDB

[Fuerchau]

Wenn du das über STRSQL direkt auf der AS/400 ausprobierst:
"CALL QSYS/QCMDEXC('ADDLIBLE LIB(LIB1)', 0000000018.00000)"
"CALL QSYS/QCMDEXC('ADDLIBLE LIB(LIB1)', 0000000018,00000)"

funktionieren beide ! (Decimal-Komma oder -Punkt sind egal)
Wichtig ist, dass die Parameter durch KOMMA UND LEERZEICHEN getrennt werden.

Über IBMDA400 gilt:
"{{CALL QSYS.QCMDEXC('ADDLIBLE LIB(LIB1)', 0000000018.00000)}}"
Aufrufkonventionen SQL statt SYSTEM (d.h., Qualifizierung mit Punkt statt Schrägstrich).

Ich hatte allerdings auch diverse Schwierigkeiten und habe deshalb eine Prozedur erstellt, die ich dann direkt per CALL (ohne geschweifte Klammern) aufrufen konnte.
Ausserdem verwende ich nicht IBMDA400 sondern den ODBC-Treiber von CA, der ist einfach besser als IBMDA400.

[Sven Schneider]

Also ich hab das mal getestet :

Wenn ein Command wie QCMDEXC über das ADODB.Command Objekt aufgerufen wird, sind folgende Hostserver im Zugriff.

1. Remote-Command Server QZRCSRVS, wenn
.CommandText = "{{CALL QSYS/QCMDEXC PARM('ADDLIBLE LIB(LIBRARY1)' 0000000022.00000)}}"
oder
.CommandText ={{CALL /QSYS.LIB/QCMDEXC.PGM('ADDLIBLE LIB(LIBRARY1)' 0000000022.00000)}}

2. Database Server QZDASOINIT, wenn
.CommandText = "{CALL QSYS.QCMDEXC('ADDLIBLE LIB(LIBRARY1)', 0000000022.00000)}"
oder
.CommandText = "CALL QSYS.QCMDEXC('ADDLIBLE LIB(LIBRARY1)', 0000000022.00000)"

Da der ADDLIBLE ja im QZDASOINIT erfolgen soll, damit die Triggerprogramme gefunden werden, ist in den Beispielen eine {..} zu viel.
Zwei geschweifte Klammern rufen immer den Remote-Command Server, weile der CommandText dann von IBMDA400 als Command interpretiert wird und nicht als SQL-String !!!.

Hab das eben auch in der technischen Doku zu OLE DB für IBMDA400 gefunden (ist bei iSeries access als Windows-Hilfe Dokument cwbzmtch.hlp dabei):

"Einfache geschweifte Klammern geben an, dass eine gespeicherte SQL-Prozedur aufgerufen werden soll. Doppelte geschweifte Klammern geben an, dass ein iSeries-Programm aufgerufen werden soll."


Sven.

[Fuerchau]

Dabei ist natürlich darauf zu achten, dass die Prozedur auch definiert ist (siehe meine Beispiele in obigem Link zu CREATE PROCEDURE).

[Sven Schneider]

Dabei ist natürlich darauf zu achten, dass die Prozedur auch definiert ist (siehe meine Beispiele in obigem Link zu CREATE PROCEDURE).

Sorry Baldur, dem muss ich wiedersprechen.
Externe Prozeduren müssen nicht registriert sein, SQL-Prozeduren werden automatisch erstellt (C-PGM-Objekt) und registriert. DB2 kann externe Prozeduren trotzdem per SQL-Call aufrufen.

Einen Nachteil hat das aber schon. Als Entwickler kann ich dann nicht auf die Parameter (z.B. .parameters(1)) zugreifen, d.h. ich muss die Parameter immer im Call direkt und im richtigen Format füllen. Ein prepared SQL-Call geht damit nicht.

Deswegen funktionieren die oben angegebenen SQL-CALLs auch. (ADDLIBLE)

Und wenn ich das ganze in doppelte {{.. }} setze, dann wird sowieso der remote command server aufgerufen und hier hat CREATE PROCEDURE eh keine Bedeutung.

Aber noch mal zurück zum Thema.
Das Problem war das im QZDASOINIT-Job die Triggerprogramme der zu aktualisierenden Tabelle nicht gefunden wurden.
Hier geht also nur ein SQL-Call mit ADDLIBLE im aktuellen QZDASOiNIT-Job.
Weil Triggerprogrgramme nicht die DB2-Namingkonventionen (*SYS oder *SQL) sondern immer in der *LIBL suchen, wenn in den Triggerprogrammen dynamische unqualifizierte CALLS existieren.

Und leider gibt es bei IBMDA400 nur die properties "default collection" und "catalog library list, welche aber beide keine Auswirkungen auf die Bibliotheksliste haben.
Im Gegensatz zum ODBC-Treiber, wo ich mit dem Parameter DBQ die Bibliotheksliste setzen kann.
Deswegen auch noch mal die Empfehlung von Baldur Fürchau den CA-ODBC-Treiber in Verbindung mit den ADO-Objektenklassen zu verwenden:

cn400.Provider = "MSDASQL"
cn400.Open "DSN=MEINEDSN; DBQ=LIB1,LIB2"

Wenn man keine ODBC-Datenquelle anlegen will, geht dann sogar :

cn400.Open "DRIVER={Client Access ODBC Driver (32-bit)};SYSTEM=MEINEAS400;DBQ=LIB1,LIB2"

Hinweis :
Falls kein Provider festgelegt wird, wird die Eigenschaft standardmäßig mit MSDASQL (Microsoft OLE DB Provider für ODBC) vorgegeben.


Sven