SQL Update

[BenderD]

Über StrSql hätte noch weiterblättern müssen und habe Enter gedrückt - so einfach
Journal ist eingeschaltet habe aber damit noch nie zurückgedreht

RMVJRNCHG ist Dein Freund, ist aber Waffenschein pflichtig und wenn Änderungen hinterherkamen, geht das sowieso nicht mehr wirklich. Sinnvoll ist in jedem Fall vorher mit DSPJRN mit Selektion auf Job und Zeit, um zu sehen wohin überall geschrieben wurde. Erst denken, dann handeln: der zweite Fehler ist immer der schlimmere!

D*B

[B.Hauser]

Vielleicht noch ein Tipp für die Zukunft:

Ändere die Option Commit im STRSQL von *NONE auf *CHG (F13 --> Auswahl 1 --> Commit)

Sofern Du jetzt versuchst eine Tabelle/phys.Datei, die nicht in einem Journal aufgezeichnet ist, wird der Update/Insert/Delete schief gehen, es sei denn Du würdest WITH NC (= With NO COMMIT) am Ende des SQL-Befehls angeben.
Fehlermeldung: YOURFILE in YOURLIB für Operation ungültig.
Damit weißt Du dann: Hoppla Vorsicht! Am besten die Daten zuerst sichern.

Wenn Deine Dateien aufgezeichnet sind und Dir passiert wieder das gleiche Malheur, kannst Du Dich gemütlich zurücklehnen und warten bis der Update fertig ist.
Im Anschlusse gibst Du ROLLBACK ein, Datenfreigabe und die Daten werden auf den Stand vor dem Update zurückgesetzt.

Wenn Du geprüft hast, ob alle Daten korrekt upgedated sind, musst DU einen COMMIT ausführen.
Sofern Du den COMMIT vergisst bleiben die geänderten Sätze gelockt bis entweder in Deinem Job ein Commit oder Rollback ausgeführt wird, oder der Job beendet wird. Wird der Job übrigens beendet, ohne dass Commit ausgeführt wurde, egal ob normal oder abnormal, werden die geänderten Daten ebenfalls zurückgesetzt.

Birgitta

[co_steffl]

@Bender
Änderungen hinterher kamen nicht. Mit DSPJRN habe ich die Records schon gefunden. Jedoch bin ich mir nicht sicher wie ich den RMVJRNCHG anwenden muss. Ich sehe die Sätze UB + UP

[BenderD]

am Besten suchst Du Dir im Journal die erste und letzte Journal ID und dann kannst Du mit RMVJRNCHG die Dtaeien angeben und von JournalId bis Journal Id, wobei von > als bis ist, also rückwärts.

Ansonsten noch der Tip, dass man bei Bulk Operationen (also sehr vielen zu ändernden Sätzen mit interaktivem SQL und Commit sehr sehr vorsichtig sein muss: man sammelt da unzählige Sperren ein, kann die gesamte Kiste dicht knebeln und die laufende Operation lässt sich nicht abbrechen, aber konkurriernde Jobs brechen ab, wegen der Sperren.

D*B

[co_steffl]

Hallo
OK. Dank an alle
Ich kann zwar genau raussuchen welche Records betroffen waren. Aber ich kann nicht sagen ob die Records bereits anderweitig geändert wurden. Da ich annehme das der Rollback (RMVJRNCHG) auf Record Ebene basiert kann ich auch nicht sagen ob ich mir damit noch mehr kaputt mache. Also macht das Jrn so auch keinen Sinn. Wenn es auf Feldebene arbeiten würde wäre das Ok.

Also muss ich einen Weg über RPG suchen. Danke nochmal

Gruß
co_steffl

[BenderD]

...
- dspjrn output(*outfile) mit Eingrenzung auf die Datei sagt einem auch, ob Änderungen danach waren.
- auf meiner OpenSource Seite ist ein Programm, das einem die Journalsätze aufbereitet in eine Datei stellt. damit kann man mit einem SQL Script sogar Deltas rausnehmen.

D*B

[co_steffl]

OK Danke für den Tipp
werde mir das mal anschauen.

Gruß
co_steffl

[co_steffl]

@BenderD

OK. Habs ausprobiert. Läuft Super. Kann ich bestimmt mal öfter gebrauchen.
Danke f. d. Arbeit

Gruß
co_steffl