iSeries ODBC DB2 Aktualisierungen unter Vista

[Krischan]

Hallo,

nachdem ich nun fast 4 h mit Experimenten und Suchen aufgegeben habe, möchte ich mein kleines Problem hier mal online stellen, in der Hoffnung das es jemand schon gelöst hat.

Wir fahren eine iSeries mit V5R3 und dem neusten Servicepack welches lt. IBM auch Vista Ultimate 32 bit unterstützen soll.

Mittels Access und ODBC (ODBC-Zugriffsmodus verwenden) greife ich auf eine DB2 Datenbank zu und möchte gerne dort Inhalte verändern und speichern. Nach dem Verlassen des geänderten Datensatzes bekomme ich jedoch eine Fehlermeldung:
ODBC Aktualierung in einer verknüpften Tabelle XXX fehlgeschlagen.
[IBM][iSeries Access ODBC-Treiber][DB2 UDB]SQL7008 - XX in XX für Operation ungültig. (#-7008).

Es sei noch zu erwähnen, das das gleiche unter XP einwandfrei funktioniert.

Über jeden Tip würde ich mich freuen.

Gruß und schönes Wochenende
Christian Loff

GELÖST: Wenn man zu blind ist und die Routine glaubt zu kennen und Einstellungen meint schon längt vorgenommen zu haben:
Normalerweiese deutet das auf fehlende Journalisierung hin.
In den Verbindungseigenschaften (ODBC-Config) in den Erweiterten Eigenschafte "Sofortiges Commit (*NONE)" auswählen.

[GutmannHGW]

Dieses Commit bewirkt was?
Erfolgreiche Übertragung JA/NEIN?

[woki]

Wenn Commit immediate = *NONE gesetzt ist, wird ODBC jede Datei updaten. Egal ob es ein Datei-Journal gibt oder nicht.

[GutmannHGW]

Wenn COMMIT auf True steht u. die Datei kein Journal hat kracht es dann?

Ist das Transaktionsprotokoll beim SQL 2005 Server vergleichbar mit dem des Journals auf der DB2?

[woki]

Hier 2 Artikel zu dem Thema:
The Four Hundred - Admin Alert: Curing Access-to-ODBC Blues
The Four Hundred Admin Alert: Feedback on ODBC Errors and WebSphere Express Installs

[GutmannHGW]

Ah interessant!

Ich hab mal nachgesehen, in meinem ODBC

Commit-Modus: "Lesen ohne COMMIT (*CHG)

Hatte bisher auch wunderbar geklappt. Den Unterschied zu *NONE weiß ich nicht.

[BenderD]

Commit Steuerung bewirkt, dass Transaktionen geklammert werden können und die Datenbank sicherstellt, dass sie nicht von konkurrierenden Transaktionen beeinflusst werden. Im DB 2 wird das mit Satzsperren sicher gestellt und setzt Journalisierung voraus (damit man mit rollback zurück setzen kann, wenn es einen Konflikt gibt).
Ein einfaches Beispiel warum das einstellen von Auto Commit oder *none wenn man updates macht, fast immer Unfug ist:
Benutzer A will eine Lagermenge um 10 erhöhen, gleichzeitig will B um 3 erhöhen
- A liest den momentanen Inhalt von 12
- B liest ebenfalls 12
- A schreibt 22 rein
- B schreibt 15 rein
Resultat 12 + 10 + 3 = 15

D*B

[B.Hauser]

Ah interessant!

Ich hab mal nachgesehen, in meinem ODBC

Commit-Modus: "Lesen ohne COMMIT (*CHG)

Hatte bisher auch wunderbar geklappt. Den Unterschied zu *NONE weiß ich nicht.

Solange Du nur Daten aus nicht aufgezeichneten Dateien liest, mach der Commitment Level *CHG auch keine Probleme. (Auch wenn das Ganze unsauber angegeben ist!)

Da Du aber, wie oben gesagt "Inhalte verändern und speichern
" möchtest, müssen die Dateien bei *CHG aufgezeichnet werden. Commitment Controll stellt sicher, dass eine Transaktion (alle Aktionen zwischen 2 Commits) entweder komplett ausgeführt oder nicht ausgeführt werden, d.h. eine Transaktion wird mit Commit beendet und damit festgeschrieben oder durch Angabe des Befehls Rollback bis zum vorhergehenden Commit zurückgesetzt. Die veränderten Datensätze bleiben gesperrt und erst durch Commit oder Rollback freigegeben.

Wird ohne Journalisierung und ohne Commitment Control gearbeitet, ist ein Zurücksetzen im nicht möglich!

Werden die Dateien nicht in einem Journal aufgezeichnet und in den entsprechenden Dateien müssen Daten hinzugefügt, geändert oder gelöscht werden, muss mit Commitment Level *NONE gearbeitet werden.

M.E. ist es heute sträflicher Leichtsinn physische Dateien oder SQL Tabellen nicht aufzuzeichnen und ohne Commitment Control zu arbeiten.

[BenderD]

das ist die default Treiber Einstellung und die ist auch so sinnvoll, denn sie stellt eben sicher, dass ein update nicht möglich ist, wenn man nicht journalisiert; soweit man per ODBC (oder SQL) lediglich liest (und über RPG record level die Daten erstellt), braucht man dann nicht unbedingt ein Journal.

D*B

PS: freut mich, dass sich die Einsicht verbreitet, dass man Journal und Transaktionskontrolle verwendet!

Solange Du nur Daten aus nicht aufgezeichneten Dateien liest, mach der Commitment Level *CHG auch keine Probleme. (Auch wenn das Ganze unsauber angegeben ist!)

[B.Hauser]

@Dieter

PS: freut mich, dass sich die Einsicht verbreitet, dass man Journal und Transaktionskontrolle verwendet!

auch wenn wir sonst nicht immer der gleichen Meinung sind, in dieser Beziehung habe ich Dir sicher noch nie widersprochen.

Bei mir wird jede Popel-Datei aufgezeichnet (und das schon seit mindestens 10 Jahren), was bisweilen schon bei Kunden, Erstaunen hervorgerufen hat, weil sich die Dateien für die Hochverfügbarkeitslösung nicht nochmals journalisieren lassen wollten.

Birgitta