View Full Version : Linked Server von SQL2008 zu AS400 zeigt keine Bibliotheken
Hallo,
wir möchten von einem SQL2008-Server auf unser Testsystem mit OS 5.2 zugreifen.
Auf unserem Livesystem V 5.4 klappt das wunderbar mit folgender Verbindung:
Anbieter: IBM DB2 for i5/OS IBMDASQL OLE DB PRovider
Anbieterzeichenfolge: "default collection = QGPL"
Unter Sicherheit haben wir den Namen und das Kennwort eines User mit *SECOFR Berechtigung eingegeben - um Berechtigungsprobleme auszuschließen.
Auf V5.4 klappt das wunderbar, ich kann alle Tabellen der Bibliothek einsehen und SQL darauf ausführen.
Auf dem Testsystem aber nicht, die Tabellen der Bibliothek werden mir nicht angezeigt.
Muss das auf der AS400 noch was gestartet werden oder geht es so nicht mit OS 5.2?
Danke für euere Hilfe
HS
Ist bei beiden Systemen die Default Collection auf QGPL gesetzt?
Ist vielleicht bei einem System zusätzlich eine Bibliotheksliste gesetzt und beim anderen nicht?
Birgitta
Hallo Birgitta ,
QGPL habe ich nur als Beispiel reingeschrieben.
In Wirklichkeit steht dort einen Bibliothek unseres ERP-Systems. Ist bei beiden aber identisch.
Gruß
HS
Das Problem ist ggf. die Inkompatibilität des Treibers von V5R4 zu V5R2.
Wenn du V5R4-Treiber eingesetzt hast, stehen bestimmte Funktionen für V5R2 nicht zur Verfügung, da sich die internen SQL-Aufrufe diesbezüglich verändert haben.
Umgedreht können V5R2-Treiber aber auf V5R4-System zugreifen (aber nicht mehr auf V6 und höher).
Wenn du die Verbindung im SQL-Server offen hast, kannst du auf der AS/400 per
"WRKOBJLCK <USER> *USRPRF"
den zugehörigen QZDASOINIT-Job ermitteln.
Der OLEDB/ODBC-Treiber versucht einen CHGLIBL per QCMDEXC-Aufruf.
Du kannst also die Bibliotheksliste des Job's prüfen und ebenso ggf. das Joblog, ob Fehler aufgetreten sind.
Alternativ hilft dann ggf. nur noch das Anpassen des Systemwertes QUSRLIBL oder in der Jobbeschreibung für QZDASOINIT-Job's den USRLIBL-Teil.
KingofKning
04-07-12, 08:58
Das Problem ist ggf. die Inkompatibilität des Treibers von V5R4 zu V5R2.
Wenn du V5R4-Treiber eingesetzt hast, stehen bestimmte Funktionen für V5R2 nicht zur Verfügung, da sich die internen SQL-Aufrufe diesbezüglich verändert haben.
Umgedreht können V5R2-Treiber aber auf V5R4-System zugreifen (aber nicht mehr auf V6 und höher).
Wenn ich Dich richtig verstehe, muß ich beim Umstieg auf einer V7R1 Kiste alle PCs die ODBC machen mit dem neuen Client Access ausstatten?
GG
Vielen Dank für die Antwort.
Joblog sagt mir folgendes:
Job . . : QZDASOINIT Benutzer : QUSER Nummer . . . : 051029
Job 051029/QUSER/QZDASOINIT im Subsystem QSERVER in QSYS am 04.07.12 um
09:53:58 gestartet. Job im System am 04.07.12 um 09:53:58. angekommen.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Benutzer XXX an Client <unsere ip> ist mit dem Server verbunden.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'.
Meldung " Auflösung zu Objekt ODBCAUT nicht möglich. Art und Subart X'0201',
Berechtigung X'0000'. "
kommt mehrfach
Den Systemwert habe ich mal geändert, bringt aber leider auch nichts.
Kann hier was falsch sein:
In WRKDBDIRE sehe ich folgende Einstellung:
Relationale Datenbank . . . . . : RCHASN32
Ferner Standort:
Ferner Standort . . . . . . . : *LOCAL
Art . . . . . . . . . . . . : *IP
Port-Nummer oder Servicename . : *DRDA
Ferne Authentifizierungsmethode:
Bevorzugte Methode . . . . . : *ENCRYPTED
Einfachere Authentifizierung
zulassen . . . . . . . . . : *ALWLOWER
Text . . . . . . . . . . . . . . : Eintrag durch System hinzugefügt
Art der relationalen Datenbank . : *LOCAL
Das scheint was spezielles des SQL-Servers oder eures Systems zu sein.
Ein Programm namens ODBCAUT gibt es so eigentlich nicht.
Prüfe mal auf dem funktionierenden System das Joblog.
Mit dem OLEDB-Treiber von CA habe ich im Wesentlichen immer Probleme gehabt.
Deshalb empfehle ich hier auch eher den ODBC-Treiber.
Der Linkedserver unterstützt ebenso ODBC-Verbindungen per DSN. Zumal die DSN-Konfiguration besser unterstützt wird und der DEBUG-Modus besser konfigurierbar ist.
Was ODBC und V6/V7 angeht, so ist das richtig. Es ist mindestens CA-V6 erforderlich.
Bisher hatte ich auch immer V5R2 im Einsatz und konnte zu verschiedenen Systemen von V4R3 (ja, die gibts noch) bis V5R4 verbinden.
Mit V6R1 war dann auch das CA V6 erforderlich.
Für die 5250-Emulation war das unerheblich, schließlich hat sich da sogut wie nichts verändert.
Der DBDIRE ist übriges identisch auf dem Livesystem. scheint also zu passen.
Komme nochmals zurück aufs Joblog:
Die Fehlermeldung mit ODBCAUT bekomme ich nicht im Live, bringt uns das auf die Spur?
Das Objekt gibt es übrigens weder auf der 5.2 noch auf der 5.4 Maschine...
Wir probieren es mal mit ODBC, vielleicht klappt das ja.
Der RDB-Eintrag ist nicht so wichtig, da, wenn dieser fehlt, der Systemname (DSPNETA) als RDB-Name verwendet wird.
DRDA ist ein anderes Protokoll (DB2/DB2Connect) und ist nicht ODBC/JDBC.