ODBC Fehler

[Starocotes]

Hi

ich habe ein seltsammes Problem das ich aktuell nicht so wirklich lösen kann.

Ich versuche unter Windows 7 (32bit) in Access 2007 eine Tabelle von der AS/400 zu verknüpfen.

Wenn ich das auf einem Rechner mache wo der Client Access 5.4 installiert ist klappt das auch. Wenn ich das aber mit einem Client Access 6.1 versuche dann bekomme ich einen Fehler:

"SQL0204 SQLSTATISTICS der Art *N in SYSIBM nicht gefunden"

Auf der AS/400 meldet er mit das dann auch so:

"SQLSTATISTICS der Art *N in SYSIBM nicht gefunden. "

Laut dem hier: https://www-304.ibm.com/support/docv...256d180052d504

kann ich die sysibm neu erstellen lassen was ich auch schon gemacht habe, SQLSTATISTICS ist immer noch nicht da.


Noch jemand ne Idee? Vor allem warum es mit V5R4 geht?


Ach ja, wenn ich das einmal eingebunden habe kann ich ohne weitere Probleme auch mit dem V6R1 auf die eingebundenen Tabellen zugreifen.

[Fuerchau]

Das ist ein Problem der SQL-Packages in der QGPL.
Zur Optimierung werden SQL-Befehle auf der AS/400 automatisch in SQL-Paketen abgelegt.
Leider besteht da diesmal ein Versionskonflikt, so dass der gespeicherte Befehl nicht mehr zum System kompatibel ist.
Lösung:
Löschen aller *SQLPKG's aus der QGPL (QZDAPKG kann nicht gelöscht werden, hierzu gibts aber einen Forumbeitrag, machmal auch nicht nötig).
Achtung: ODBC-verbindungen sollten natürlich nicht aktiv sein!

Die SQL-Pakete werden automatisch wieder erstellt.

Ich habe es mir schon länger angewöhnt, in der ODBC-Konfiguration als Lib für das SQL-Paket die QTEMP anzugeben.
Performancenachteile gibt es dadurch fast gar nicht, aber ich bin sicher, dass das Paket zum Release passt.

[Starocotes]

Ich habe eignetlich immer die Packetverwendung komplett ausgeschaltet. Habe jetzt zu Testzwecken mal eingeschaltet und mit verschiedenen Bibliotheken (auch QTEMP) probiert aber immer noch das selbe Problem.

Das Packet wird auch gar nicht erstellt.

[Fuerchau]

Hast du denn auf der AS/400 auch V6R1 ?
Zwischen V5R4 und V6R1 besteht diesbezüglich halt ein Unterschied, der nicht mehr kompatibel ist.

SQLStatistics ist eine ODBC-Funktion um Informationen über Schlüssel und Indizes zu erhalten.
Diese ist von V5R4 zu V6R1 von einem SQL-Select in einen "Call Procedure" geändert worden.

Greifst du nun mit CA V6R1 auf ein System mit niedrigerem Release zu, kann das nicht mehr klappen.

Für normale Client-Programme ist die CA-Version meistens unerheblich, da ja nur SQL-Befehle direkt laufen.

MS-Access benötigt aber die Index-Informationen und auf anderem Wege sind die nicht zu bekommen.

[Starocotes]

Ja, das Zielsystem ist ein 6.1er.

Das wirre ist ja das der SQLStatistics aufruf von einem Client der 5.4 installiert hat auf das selbe Zielsystem funktioniert.

[Fuerchau]

Dann musst du ggf. doch mal das QZDAPKG löschen, ist hier im Forum irgendwo beschrieben.

Ansonsten schau mal, ob du noch irgendwo *SQLPKG's hast, die auf MSxxx oder XXXFBA, XXXVBA oder so lauten und nicht zu expliziten AS/400-Anwendungen gehören.

[Starocotes]

Das hab ich jetzt gemacht, dummerweise danach erst festgestellt das die *SQLPKG in der QSYS QSQLPKG2 und QSQXDPKG fehlen.

Ich werde heute Nachmittag mal Sicherungen durchforsten, weiss aber nicht ob die da drauf sind.

Hat hier vielleicht jemand ne 6.1er und kann mit die beiden sichern und zur Verfügung stellen?

[Starocotes]

So, jetzt bin ich wieder da wo ich am Anfang war. ODBC grundsätzlich geht wieder QZDAPKG hat er automatisch neu angelegt und ich bekomme wieder den Fehler mit dem SQLStatistics.

Langsam wirds lästig.

[Fuerchau]

Dann würde ich halt noch mal PTF's und Servicepacks von CA überprüfen.
Bei meinem anderen Kunden funktioniert die Konstellation nach dem Löschen der SQLPKG's.

[Starocotes]

Dann würde ich halt noch mal PTF's und Servicepacks von CA überprüfen.
Bei meinem anderen Kunden funktioniert die Konstellation nach dem Löschen der SQLPKG's.

Danke für die Antwort selbst am Samstag.

Das aktuellest CUM Tape ist auf der iSeries und ebenso das neuste CA PTF auf dem Client.

Ich werde also erstmal eine Kiste mit 5.4 sicher laufen lassen um dort notfalls die benötigten Tabellen neu einbinden zu können.

[Starocotes]

So, hab jetzt anderweitig eine Antwort bekommen:

Neben den Tips die hier schon kamen wurde noch vorgeschlagen die CATALOGOPTIONS auf 8 zu setzen, weil damit so getan wird als wäre es ein V5R4. Das musste ich zwar über REGEDIT machen weil die Option im ODBC Manager nicht drin ist, aber es hat funktioniert.


developerWorks : Information Management : DB2 for i : Strange ODBC Problem in Access ...

[Fuerchau]

Sehr schön, nur leider finde ich die Doku dazu nicht.
Die Option 8 ist nicht beschrieben, mal wieder ein interne IBM-Spezifikation?

Zusätzlich ist dies eine Bit-weise Option, dessen Default = 3 ist.
Also sollte der Wert doch dann eher 11 (8 + 3) sein?

Zu beachten ist auch, dass über die ODBC-Konfig im Register "Katalog" der Wert ggf. wieder überschrieben werden könnte, wenn man an der Konfig was ändert.