PDA

View Full Version : MSQuery hängt sich auf beim Zugriff auf AS400



Seiten : [1] 2

ozean
09-09-09, 14:27
Hallo liebe Gemeinde,

ich habe folgendes Problem:

Beim erstellen einer neuen Abfrage im Excel beim Zugriff auf AS400 hängt sich MSQuery auf. ODBC-Datenquelle habe ich als System-DNS angelegt, wobei ich den iSeries Access ODBC Treiber 11.00.11.00 beuntzt habe.
Also ich gehe dann im Excel auf "Neue Abfrage erstellen", wähle meine ODBC-Datequelle, die Verbindung zu AS400 wird aufgebaut, es kommt ein Fenster, (geteilt in zwei Spalten), wo ich auf der rechten Seite alle Tabellen von AS400 sehe. Sobald ich aber irgendwas in diesem rechten Fenster anklicke, geht nichts mehr (Query hängt). Es hilft nur dieses Fenster mit dem X oben rechts zu schließen, wobei die Meldung erscheint "MSQuery hat einen Fehler verursacht..." Ich habe auch schon eine Weile gewartet, dachte mir Query arbeitet in diesem Moment, aber es passierte trotzdem nichts. Ich verwende Office 2003 mit SP3 und Windows XP Pro mit SP3. Übrigens mit Access habe das gleiche Problem, ich kann zwar die AS400 Tabellen beim Import sehen, aber sobald ich auf Importieren klicke, hängt sich Access auf. Komischerweise funktionieren die gespeicherten Query-Abfragen problemlos, ich kann aber keine neue mehr erstellen. Wir haben vor kurzem einen Releasewechsel des WAWI-Programms auf AS400 gehabt, und seitdem funktioniert es mit den neuen Abfragen nicht mehr. Auf der Windows-Seite wurde nichts geändert, es muss also an AS400 liegen. Es wurde mir aber von der Firma, welche den Release-Wechsel durchgeführt hat, zugesichert, dass an der AS400 Konfiguration nichts geändert wurde.
Vielleicht hatte jemand ein ähnliches Problem gehabt und Lösung dafür gefunden?

KingofKning
09-09-09, 15:11
Hast Du mal nachgesehen ob es auf der AS/400 bei den ODBC-Jobs Fehlermeldungen gibt?
Berechtigungen?

GG

Fuerchau
09-09-09, 17:21
Du kannst per "WRKOBJLCK UserName *USRPRF" den zuständigen QZDASOINIT-Job ermitteln und dort mal ins Joblog schauen.

In der ODBC-Konfig kannst du im Register "Diagnose" mal den STRDBG aktivieren um ggf. erweiterte Fehlermeldungen zu sehen.
Im Register "Katalog" sollte "Suchmuster aktivieren" nicht angehakt sein. Dies führt nämlich zu temporären Indizees auf der QSYS2/SYSCOLUMNS, falls eine Bibliothek einen Unterstrich "_" enthält. ODBC versucht nämlich dann, die Spalteninformationen per "like" zu ermitteln und das kann dauern.

ozean
10-09-09, 11:42
Danke für eure Infos! An der Berechtigung auf AS/400 kann es eigentlich nicht liegen, kann ich mir zumindest nicht vorstellen.
Die Optionen in der ODBC-Konfig habe ich so eingestellt, leider hat es nichts gebracht. QUERY hängt und es kommt auch keine Fehlermeldung. :(

ozean
10-09-09, 11:44
Was aber die Befehle auf AS/400 angeht, da habe ich keine Ahnung davon. Ich kann solche Vorschläge nur an unseren AS400 Spezialisten weiterleiten. Er kann aber nur verzögert antworten.

Fuerchau
10-09-09, 13:28
Dann wird auf eine Antwort der AS/400 gewartet.
Jetzt muss dein AS/400-Spezi mal im System nachschauen.

ozean
14-09-09, 09:40
AS400 Spezialist sagt, dass alles in Ordnung ist. Es gibt auch keine Fehlermeldungen. Die Verbindung wird aufgebaut, der User ist eingeloggt, beim Klick auf das Auswahl-Fenster im Query wird ein Datenpaket vom Rechner zu AS400 geschickt und ein von der AS400 zum Rechner. Ich denke, das diese sind begrüßt haben. Danach geht nichts mehr.
Diese Pakete konnte man mit dem Programm Wireshark sehen.
Kann es vielleicht am Netzwerk selbst liegen? Wir haben bei uns im Netzwerk eine Firewall/Proxy. Diese fundiert auch als Gateway für alle Rechner. Dass da irgendwas blokiert wird?
Kann mir eigentlich nicht vorstellen, da es früher funktioniert hat.

Ich weiß nicht mehr, wo ich anfangen soll :(

Fuerchau
14-09-09, 10:22
So pauschal, dass alles in Ordnung ist, kann man das nicht gelten lassen.
Ein Netzwerk-Protokoll besagt da überhaupt nichts.

Dein Spezi soll doch bitte den obigen Weg mal nachvollziehen (WRKOBJLCK ...), wenn dein MS-Query hängt.

Starte vorher in deiner ODBC-Konfig über Diagnose mal den STRDBG, so dass der Spezi im Joblog auch was sehen kann.

Manchmal kann auch die Ursache ein "kaputtes" SQLPKG auf der AS/400 sein.
Um dieses auszuschließen geh in deine ODBC-Konfig ins Register "Pakete" und trage als Paketbibliothek "QTEMP" ein.
Das stellt sicher, dass nicht auf "alte" Pakete referiert wird.

ozean
14-09-09, 13:15
Ok, werde ich ihm sagen.

Die Sache mit QTEMP hat nichts gebracht. Hängt auch wieder.

mors
15-09-09, 15:57
Hallo zusammen,

ich bin dann wohl der Spezi. ;)

Wir haben STRDBG gestartet und dabei ist folgendes rausgekommen:

Joblog

Job 179454/QUSER/QZDASOINIT im Subsystem QUSRWRK in QSYS am 15.09.09 um
11:15:27 gestartet. Job im System am 15.09.09 um 11:15:27. angekommen.
Benutzer POHL an Client 192.168.80.8 ist mit dem Server verbunden.
DESCRIBE für vorbereitete Anweisung STMT0002 beendet.
PREPARE für Anweisung STMT0002 beendet.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Abfrageoptionsdatei kann nicht abgerufen werden.
Abfrageoptionsdatei kann nicht abgerufen werden.
Alle Zugriffspfade wurden für Datei QADBXRDBD berücksichtigt.
Zugriff nach Eingangsfolge für Datei QADBXRDBD verwendet.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
Cursor SQL_CUR00FD45C0 eröffnet.
Offener Datenpfad (ODP) gelöscht.
Cursor SQL_CUR00FD45C0 wurde geschlossen.
STATEMENT TEXT FOUND : SELECT TABLE_NAME, TABLE_TYPE, COLUMN_COUNT,
TABLE_TEXT, LONG_COMMENT, TABLE_SCHEMA, SYSTEM_TABLE_NAME,
FILE_TYPE FROM QSYS2/SYSTABLES WHERE (((TABLE_TYPE = 'T' OR TABLE_TYPE
= 'P') AND TABLE_NAME NOT LIKE 'QIDCT%' AND
TABLE_NAME NOT LIKE 'QADB') OR ((TABLE_TYPE = 'L' AND
TABLE_NAME NOT LIKE 'QIDCT%') OR (TABLE_TYPE = 'V' AND TABLE_NAME
NOT LIKE 'SYS%')) OR (TABLE_TYPE = 'A')) AND TABLE_SCHEMA IN
(?,?) ORDER BY TABLE_TYPE, 
STATEMENT NAME FOUND : FIFAABTALL0002.
STATEMENT NAME FOUND : FIFAABTALL0002.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.
Abfrageoptionsdatei kann nicht abgerufen werden.
Alle Zugriffspfade wurden für Datei QADBXREF berücksichtigt.
Alle Zugriffspfade wurden für Datei QADBXMQT berücksichtigt.
Datei QADBXREF in Verknüpfungsposition 1 verarbeitet.
Datei QADBXMQT in Verknüpfungsposition 2 verarbeitet.
Empfohlener Zugriffspfad für Datei QADBXREF.
****: Debug-Nachrichten für Abfrage werden beendet.
ODP erstellt.
Blockung für Abfrage.
Cursor FILE eröffnet.
Offener Datenpfad (ODP) gelöscht.
Cursor FILE wurde geschlossen.
STATEMENT TEXT FOUND : SELECT COLUMN_NAME, TABLE_NAME, DATA_TYPE, LENGTH,
NUMERIC_SCALE, IS_NULLABLE, LONG_COMMENT, NUMERIC_PRECISION,
TABLE_SCHEMA, NUMERIC_PRECISION_RADIX, COLUMN_TEXT, CCSID,
SYSTEM_TABLE_NAME, SYSTEM_COLUMN_NAME, ORDINAL_POSITION FROM
QSYS2/SYSCOLUMNS WHERE TABLE_NAME = ? AND SYSTEM_TABLE_SCHEMA = ?
ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION.
STATEMENT NAME FOUND : FDLCDALCLL0001.
STATEMENT NAME FOUND : FDLCDALCLL0001.
Abfrageoptionsdatei kann nicht abgerufen werden.
****: Debug-Nachrichten des Optimierungsprogramms für Abfrage werden
gestartet.


Da meine AS400-Kenntnisse eigentlich eher rudimentär sind, sagt mir das jetzt nicht allzuviel.
Ist es normal, dass beim ersten Auftreten von 'STATEMENT TEXT FOUND' das Statement einfach abbricht?