iSeries ODBC DB2 Aktualisierungen unter Vista

[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