Zugriff von 8.1 Client auf DB2 7.2 database
- Dieses Thema hat 9 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre, 10 Monaten vonGast.
- AuthorPosts
- 15. Juli 2004 um 14:33 Uhr #2423
Hallo Leute,
ich beziehe mich auf folgenden Beitrag:
https://www.ruban.de/cgi-bin/yabb/YaBB.cgi?board=DB220007;action=display;num=1089123332
Leider ist mir das Vorhaben nur einmal geglückt u. jetzt möchte ich gerne wissen wo der eigentliche Fehler liegt. Ich habe einen neuen DB2 7.2 Server mit folgenden Komponenten installiert:
– Workgroup Edition
– Application Development Client
– Administration ClientDanach habe ich das Fix Pak 8 eingespielt. Hiernach führte ich dann folgende Prozedur aus:
1. Wiederherstellung einer Datenbank
2. Updaten der Datenbank (db2updv7)
3. Binden der Dateien vom 8.1 Client aus an die Datenbank (db2ubind.lst, db2cli.st)Auf dem DB2 8.1 Client ist auch das aktuelle Fix Pak 5 installiert. Die gleiche Prozedur habe ich mit dem Fix Pak 11 für den Server durchgespielt.
Wo kann hier noch ein Fehler liegen? Kann mir vielleicht jemand eine genaue Schritt-für-Schritt-Anleitung zusammenstellen?
Schon jetzt vielen Dank an jeden, der sich an dieser Diskussion beteiligt.
Gruß
toette15. Juli 2004 um 19:04 Uhr #2903Hallo Toette,
ich würde es mal so beschreiben:
Am Server mit DB2 V7.2:
- Backup erstellen
- FixPak 8 oder höher einspielen
- neue Binde-Listen sqllibbnd, @db2ubind.lst und @db2cli.lst an die Server-Datenbank binden
- db2updv7 ausführen
Dann an den DB2 V8.1 Clients : (
(nur wenn unterschiedliche FixPak-Stände)- Connect an DB2 V7.2 Server Datenbank
- Binde-Listen sqllibbnd, @db2ubind.lst und @db2cli.lst an die Server-Datenbank binden
Das sollte funktionieren. Der Restore der Datenbank ist nicht erforderlich.
Ciao
Gernot19. Juli 2004 um 12:31 Uhr #3249Hi Gernot,
vielen Dank für deine Antwort. Ich habe es so gemacht u. erhalte jetzt den folgenden Fehler:
[IBM] [CLI Driver] SQL30081N Kommunikationsfehler. Verwendetes Kommunikationsprotokoll: "TCP/IP". Verwendete Kommunikations-API: "SOCKETS". Position, an der der Fehler festgestellt wurde: "IP-Adresse". Kommunikationsfunktion, die den Fehler feststellte "recv." Protokollspezifische(r) Fehlercode(s): "10054", "*", "0". SQLSTATE=08001 (#-30081)
Wenn ich aus der Kommandozeile den Connect absetze habe ich keine Probleme. Der oben beschriebene Fehler tritt auf, sobald ich per ODBC über MS-Access auf die Datenbank will. Der komplette Server-Dienst schmiert dann ab.
Die Tests habe ich auf zwei unterschiedlichen Servern durchgeführt.
19. Juli 2004 um 20:08 Uhr #3475Hi Toette,
– ein erfolgreiche Connect ist ja schon mal eine feine Sache. ;D Wie sieht’s mit einem Test-SQL-Statement aus (z.B. SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR=’SYSIBM‘)? :-/
– wird das Password in der Access/ODBC-Umgebung abgefragt?!
– versuch‘ mal eines der Objekte erneut zu verknüpfen und dann nochmal abzufragen. Kommt gelegentlich vor, dass die Verknüpfungen beschädigt werden, z.B. auch nach DROP/Re-CREATE einer Tabelle.Viel Erfolg!
Gernot22. Juli 2004 um 8:01 Uhr #3621Hi Gernot,
aus der Kommandozeile ist ein Test-sql-statement kein Problem. Ich habe auch zum wiederholten Male probiert aus Access per ODBC die Tabellen zu verknüpfen, leider schmiert der DB2-Dienst sofort wieder ab. Das Passwort wird in der Access/ODBC Umgebung abgefragt.
Für weitere Hilfe wäre ich Dir sehr dankbar.
Gruß
22. Juli 2004 um 11:10 Uhr #3731Hallo Toette,
- handelt es sich um eine ODBC System- oder um eine Benutzerdatenquelle? (Systemsteuerung, ODBC)
- Inhalt der DB2CLI.INI
- db2 list db directory, db2 list node directory, db2 list dcs directory
- db2licm -l
Dann schauen wir mal weiter.
Ciao
Gernot2. August 2004 um 8:31 Uhr #3803Hallo Gernot,
konnte mich leider erst jetzt wieder der Sache annehmen.
1. Es handelt sich um eine ODBC Systemdatenquelle
2. Inhalt der db2lci.ini
; Comment lines start with a semi-colon.
[tstcli1x]
uid=userid
pwd=password
autocommit=0
TableType="’TABLE‘,’VIEW‘,’SYSTEM TABLE’"[tstcli2x]
; Assuming dbalias2 is a database in DB2 for MVS.
SchemaList="’OWNER1′,’OWNER2′,CURRENT SQLID"[MyVeryLongDBALIASName]
dbalias=dbalias3
SysSchema=MYSCHEMA[DWCTRLDB]
DBALIAS=DWCTRLDB3. 1 db2 list db directory
Eintrag für Datenbank 1:
Aliasname der Datenbank = TEST
Datenbankname = TEST
Datenbanklaufwerk = C:
Release-Stand der Datenbank = 9.0
Kommentar Verzeichniseintragungsart = Ind
Katalogknotennummer = 0Eintrag für Datenbank 2:
Aliasname der Datenbank = DWC
Datenbankname = DWC
Datenbanklaufwerk = C:
Release-Stand der Datenbank = 9.0
Kommentar =
Verzeichniseintragungsart = Ind
Katalogknotennummer = 03.2 db2 list node directory
SQL1037W Das Knotenverzeichnis ist leer. SQLSTATE=01606
3.3 db2 list dcs directory
SQL1037W Das Knotenverzeichnis ist leer. SQLSTATE=01606
4. db2licm -l
Produktname = "DB2 Workgroup Edition"
Produktkennwort = "DB2UDBWE"
Versionsnummer = "7.2"
Verfallsdatum = "Permanent"
Maßnahme für gleichzeitig angemeldete Benutzer = "Inaktiviert"
Maßnahme für registrierte Benutzer = "Inaktiviert"
Durchsetzungsmaßnahme = "Normaler Stopp"
Anmerkung = ""
Weitere Informationen = ""Schon jetzt vielen Dank für weitere Hilfe.
Gruß
Chris5. August 2004 um 14:54 Uhr #3847Hallo Toette,
wenn ich das auf die Schnelle richtig überblicke :-/, dann stimmen doch ODBC-Registratur und DB2 Database Directory doch nicht überein! ???
Benutze den Client Configuration Assistant, um die ODBC Verbindung der Datenbank neu zu definieren.
Viel Erfolg
Gernot11. August 2004 um 14:42 Uhr #3880Ich habe über den Configuration-Assistent die Datenbank noch einmal neu gebunden. Leider hat dies aber noch nicht den gewünschten Erfolg gebracht. Es bleibt bei dem alten Fehler. Bitte um weitere Hinweise
11. August 2004 um 14:42 Uhr #3904 - AuthorPosts
You must be logged in to reply to this topic.
