DbRRollback()

[Manfred]

Hi,

nachdem ich nun auch ein wenig im Wiki mitmische(n darf), bin ich gerade bei einer Auflistung auf die Funktion DbRRollback() (komisch, habe ich die ganze Zeit übersehen) gestossen. Hat jemand von euch damit schon tiefere Erkenntnisse sammeln können und könnte seine Erfahrung hier ausbreiten? Es klingt ja zunächst recht toll, aber ist es wirklich so einfach wie man vermuten könnte? Also wenn man jetzt z.B. eine Kette von DBF hat, in die abhängig voneinander Daten schreiben muß in einem Rutsch, aber eine davon Mucken macht, man dann wieder alles vorhergehende zurücksetzen kann mit dieser Funktion? Also ein ähnliches Verfahren wie bei einer SQL Datenbank, nur eben nicht selbst geschrieben.

[georg]

Hallo, Manfred -


so wie ich die Dokumentation verstehe, bezieht sich das immer nur auf die aktuelle Zeile (= Record) einer DBF-Datei. In wie weit man das kaskadieren kann, weiss ich nicht. Wenn Du z.B. eine Rechnung erzeugst, und den Kopfsatz und drei von vier Positionssätzen geschrieben hast, kannst Du m.E. nur den letzten Positionssatz, nicht aber die beiden davor, zurückrollen.

[Manfred]

Es geht mir auch wenn erstmal darum nur 1 Satz zurück zu holen.

Meine Idee wäre, die DBF Namen in ein Array zu schreiben z.B., die alle abgearbeitet werden müssen. Das Array wird durchlaufen und schreibt DBF für DBF der Reihe nach zurück (würde bei mir einfach gehen, weil ich mit Klassen arbeite, die einfach nur einen Methode aufrufen und dann wissen, was gespeichert werden muß) und merkt sich welche zuletzt erfolgreich abgearbeitet wurde. Sollte an irgendeiner Stelle ein Problem auftauchen, wird rückwärts (oder wie auch immer) jede DBF, die schon geschrieben wurde (mit 1 Satz im Moment) "zurückgerollt". Das würde aber auch bedeuten, dass Xbase++ sich alle Felder einer DBF irgendwo im Cache hält mit den "alten" Daten. OK, sowas könnte man auch selbst programmieren, aber wenn es sowas vom System her gibt, warum dann nochmals das Rad neu erfinden?

[ramses]

@Manfred schau dir mal die Funktion AX_Transaction() von ADS an. Damit lassen sich viele Sätzte zurückholen

Cu Carlo

[Manfred]

Ich habe es mal einfach ausprobiert. Satz geändert und direkt danach ein DbRRollback() wie im Handbuch beschrieben. Da hat sich nichts geändert auf den vorherigen Wert. Scheint also nicht mal so eben zu klappen. Oder gilt das nur, wenn ein Fehler mittendrin aufgetreten ist? So genau vermag ich das aus der Beschreibung nicht zu erkennen.

[Wolfgang Ciriack]

Hallo Manfred,
also ich verstehe das so, dass das nur klappt, wenn beim Schreiben eines Datensatzes ein Fehler passiert, also bei irgendeinem replace...with.. ein Laufzeitfehler entsteht (z. B. wenn du eine Datumsfeld mit einer Stringvariablen ersetzen willst). Dieses abgefangen durch BEGIN... RECOVER...END SEQUENCE, dann kannst du, bevor ein Commit() auf dem Datenatz erfolgt ist, diese Funktion benutzen. Sobald du jedoch alles geschrieben hast und den Satz abschließt/entsperrst (impliziert ein commit) geht das nicht mehr.

[Manfred]

Hi Wolfgang,

im Beispiel steht aber ein Commit und danach kommt erst das Rollback. Oder sehe ich das jetzt falsch?

[Wolfgang Ciriack]

Ja, das siehst du falsch

Code: Alles auswählen

 bErr := Errorblock( {|o| Break(o) } ) 
 
   BEGIN SEQUENCE 
      REPLACE FIELD->TINYINT WITH nNumber 
      DbCommit() 

      ErrorBlock( bErr ) 
 
   RECOVER USING oErr 
      ErrorBlock( bErr ) 
      Alert( "Error: " + oErr:description ) 
      DbRRollback() 

   ENDSEQUENCE 

Bei REPLACE... kommt der Fehler, damit wird DbCommit() nicht erreicht, es geht weiter beim RECOVER statement und da kommt dann DbRRollback().

[Manfred]

Stimmt,

sollte mal meine Augen aufmachen.

Aber damit erübrigt sich meine anfängliche Frage, was möglich wäre, wenn man Kettenabläufe hat. Also mehrere Tabellen updatet und bei der letzten z.B. ein Problem auftaucht. Ich hatte angenomen, man könnte dann alles zurückspielen. Das ist aber dann nicht so und damit bringt die Funktion eigentlich nicht so richtig etwas. M.E.

[UliTs]

...Das ist aber dann nicht so und damit bringt die Funktion eigentlich nicht so richtig etwas. M.E.

Na ja...
Wenn man sich zumindest sicher sein kann, dass der Datensatz ganz oder gar nicht geändert wurde: das ist doch auch schon mal etwas
-
Aber so richtig klasse wird es erst, wenn man mit Transaktionen arbeitet. Und die können nun mal nur (verständlicherweise) Datenbankserver

Uli