Linked Server von SQL2008 zu AS400 zeigt keine Bibliotheken

[hs]

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.

[hs]

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

[hs]

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.

[Fuerchau]

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.

[Fuerchau]

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.

[hs]

Vielen Dank für die Unterstützung, mit ODBC klappt es jetzt einwandfrei

[Fuerchau]

Nun ja, ich weiß nicht was denn der SQL-Server bzw. der OLEDB-Treiber da so machen.

Wichtig ist folgendes:
In der QGPL werden Objekte der Art *SQLPKG angelegt.
In dem Paket QZDAPKG stehen die SQL's die vom QZDASOINIT verwendet werden.
Der ODBC/OLEDB-Treiber legt automatisch Pakete an, deren Namen in der Verbindung konfigurierbar ist, ansonsten definert er den selber.

Da SQL-Server (MS-Access teilweise ebenso) ggf. verschiedene Zugriffe versucht, kann es eben sein, dass auf V5R4 bestimmte Aktionen verfügbar sind, auf V5R2 eben nicht und somit der SQL-Server SQL-Funktionen/Prozeduren versucht aufzurufen.

Der OLEDB-Treiber unterstützt bzgl. SQL leider nicht so viel, wie der ODBC-Treiber, ins besonders Schema-Abfragen und Transaktionen.
Deshalb empfehle ich grundsätzlich den ODBC-Treiber. Dies gilt leider auch für den in CA enthaltenen .NET-Treiber.

Was also den Unterschied der Systeme angeht, so kann man das genau tatsächlich nur mit Analyse der Joblogs und SQL-Pakete feststellen.
Hierzu kann man den Debug-Modus aktivieren.