IB-Transaktionen

[HaJo]

Hallo an alle,

seit kurzem versuche ich mit diesen Komponenten zu arbeiten. Bisher habe ich ausschließlich über die BDE gearbeitet.

Aber was Transaktionen sind und wie man sie benutzt ist mir äusserst suspekt.

Kann mir jemand helfen das zu verstehen?

Braucht man pro Database nur eine oder mehrere??

Danke im Voraus
Jochen

[Albi]

Moin,

über die Transaction der Interbase wickelst du alles ab, was von oder zur Interbase geschickt wird. Sie bildet also die Verbindung zwischen einer Kompo (IBStoredProc, IBDataSet usw.) und der Interbase.

Zitat:

Aber was Transaktionen sind und wie man sie benutzt ist mir äusserst suspekt.

Nehmen wir an du hast eine Query zum lesen der Daten und eine StoredProc zum schreiben der Daten, dann brauchst Du also eine IBQuery-Kompo, eine IBStoredProc und eine Transaction. Dann brauchst Du nur bei der Query und der StProc die Database und die dazugehörige Transaction auswählen. Bei der Transaction wählst Du nur noch die Database aus.

Bevor du Daten an die IB schickst must Du also ersteinmal die Transaction öffen und wenn das fertig ist, die Transaction wieder schließen.

Code:

//zum lesen
If Not IBTrans.InTransaction Then
   IBTrans.startTransaction //startet die Transaktion
Try
  With Query1 Do  
  Begin
    open; //Wenn es mit Parameter erfolgt, dann schiebe ich das immer in ne extra Procedure 
    Edit1.Text:= Field[0].AsString;
    ...
    ...
  end;
except;
  IBTrans.Rollback //verwirft das Ergebnismenge
end;
  IBTrans.Commit; //schließt die Transaction
end;

Zitat:

Braucht man pro Database nur eine oder mehrere??

Rein theoretisch sollte das gehen aber es ist nicht empfehlenswert, da du ja so die Funktionen der Transaction entweder selber steuern oder darauf verzichten mustest. Ich nehme gerne immer eine Transaction zum Lesen und eine andere zum schreiben.

[Quake]

Gugg mal hier vorbei.
Ich denke, man benötigt pro Database nur eine Transaktion.
@Albi: Bringt das Vorteile mit 2 Transaktionen?

[Albi]

Zitat von Quake:

@Albi: Bringt das Vorteile mit 2 Transaktionen?

Ich denke schon. Sicherlich kann man das auch mit einer 1 Transaction lösen aber ich finde es ganz schön kompliziert, es ist so einfach komfortabler.

Ein kleines Bsp.: Du hast ein Prog mit mehreren Forms, die Du alle gleichzeitig bearbeiten kannst. Du machst nun das eine Form auf - startest die Transaction - und bearbeitest die Daten und sagst speichern (Transaction bleibt offen) nun noch ein weiteres Form bearbeitest auch hier die Daten und willst speichern. Nun kommt ein Fehler und es erfolgt ein Rollback, somit sind die Daten aus dem anderen Form auch nicht gespeichert.

Oder Du 2 User wollen den gleichen Datensatz bearbeiten/anschauen. Du nimmst nur eine Transaction und setzt die Trans auf Lesen-schreiben Tabellenstabilität und schon kann nur einer den DS lesen, da ja ein Lock auf diesem liegt. Oder anderherum, 2 User bearbeiten den DS ohne das eine Sperre oder sonstwas gelegt wurde, dann hat der als letztes auf speichern klickt gewonnen.

Besonders mergen wird man das, wenn man dann noch mit DBEdit arbeitet.

Also ich habe mir angewöhnt, fürs speichern und lesen zwei Transaction zu nehmen. Aber das muss im enteffekt jeder für sich selbst entscheiden, wie er mag.

[Quake]

In meiner Anwendung starte ich die Transaktion beim Programmstart und wenn ich einen Datensatz geändert habe führe ich ein CommitRetain aus.
Wenn ich dich richtig verstanden habe, bringt es aber nicht viel wenn du fürs Lesen und Schreiben eine getrennte Transaktion hast. Du bräuchtest doch nur für jedes Fenster eine eigene Transaktion, oder?
Nur mal an einem Beispiel erläutert ... In einer Bank werden Überweisungen gebucht und an dem PC werden 2 Fenster zum Überweisungen buchen geöffnet. Dann sollte jedes Fenster seine eigene Transaktion besitzen, weil die beiden überweisungen nichts miteinender zu tun haben aber in jedem Fenster hat die Abbuchung vom einen Konto und die Aufbuchung auf das andere Konto was mit einander zu tun und dabei darf nix schief gehen. Also gehört das in eine Transaktion. Das gewährleistet auch wenn die eine Buchung fehl schlägt ist die 2. Buchung nicht davon betroffen.

-Transaktion öffnen (Auf die richtige transparenz achten)
-Alles was in zusammenhang mit der einen Überweisung ist tun (lesen des Datensatzes, abbuchen vom einen Konto, aufbuchen auf das andere Konto ...)
-Wenn alles ok -> Commit oder wenn ein Fehler aufgetreten ist Rollback

Das mit den 2 User verhinderst du doch sonst auch nicht. Da hilft doch nur eine andere tranzparenz zu wählen.
Und die muss natürlich jeder selbst entscheiden welche am besten geeignet ist für ihn.

[Albi]

Das ist ja alles richtig. Ich habe mich da wohl etwas ungünstig ausgedrückt. Generell sieht es bei mir so aus, das ich für jedes Fenster ein eigene Transaktion habe. Mein Beispiel war hierauf bezogen

Zitat von Quake:

Ich denke, man benötigt pro Database nur eine Transaktion.

Und dann stimmte das was ich geschrieben habe, ansonsten ist der Ansatzpunkt ja genau der selbe wie bei mir. Nur das ich halt, die Daten in einer Transaktion behandele und in der anderen speichere. Das lesen habe ich auf Schnappschuß, so dass ich das sehe was in der DB, und speichernn habe ich Lesen-schreiben-Tabellenst. das eben nicht 2 User den gleichen DS bearbeiten können aber mehrere User den DS lesen können.

Also öffne ich Read-Trans nur zum Lesen und sobald die Daten da sind, wird diese auch gleich wieder geschlossen. Und die zum speichern wird nur in der Zeit geöffnet, wo die Daten zum Server gesendet werden. Da man ja die Trans-Zeiten so gering wie möglich halten soll.

Zitat:

In meiner Anwendung starte ich die Transaktion beim Programmstart und wenn ich einen Datensatz geändert habe führe ich ein CommitRetain aus.

ich kann dir da nur Raten ab und zu mal ein HardCommit aufzurufen, da ansonsten über kurz oder lang die Performance deiner DB abnimmt. Da durch das SoftCommit der Garbage Collector der IB nicht wirksam werden, somit werden überflüssige DS-Varianten nicht mit abgeräumt.

Im enteffekt ist das Ergebnis das gleiche, nur das ich mich so nicht um die jeweiligen Einstellungen kümmern muss (sicher weil es so bequemer ist ).

[Hansa]

Ihr betrachtet eine Transaktion IMHO zu sehr als eine Muliuser/Multitasking-Angelegenheit. Die machen aber auch in einer Einzelplatz Anwendung einen Sinn.

Es geht darum, entweder eine Reihe von Änderungen an der Datenbank alle durchzuführen oder keine. Beispiel Rechnung : Ich gebe Kunden-Nr. ein und dann ein paar Artikel und die Mengen. Was muß nun beim Speichern gemacht werden ? Die Mengen müssen vom Laberbestand abgebucht werde, es müssen für die Rechnungspositionen neue Datensätze angelegt werden, die Kunden und Artikelstatistik muß aktualisiert werden usw.

Dies könnte man z.B. alles machen, nach jeder Mengeneingabe. Wenn ich jetzt schlau bin, dann habe ich die Transaktion gestartet, schon bevor ich den ersten Artikel eingebe. Warum ? Ich habe mich nämlich vertan und für den falschen Kunden bereits 100 Rechn.-Positionen eingegeben, also sind zwar die 100 Lagerbestände richtig geändert, aber die Kundenstatistik usw. stimmt auf keinen Fall mehr. Ein DAU würde nun das alles noch einmal mit - eingeben (wenn das Programm das überhaupt zuläßt) und hoffen, daß er sich nicht vertut. Man könnte ihm aber helfen und ganz zum Schluß 2 kleine Buttons anzeigen, die er drücken muß : "alles speichern" und "alles rückgängig machen".

Was passiert jetzt im Fehlerfall mit den 100 Positionen bzw. im Programm ? In dem OnClick des einen Buttons steht einfach Transaction.Commit; Alles wird gespeichert und fertig. In dem zweiten steht Transaction.Rollback; Alle Änderungen seit dem Start der Transaction werden rückgängig gemacht. Egal welche Tabelle es betrifft. Äußerst wichtig ist hierbei der Startzeitpunkt der Transaktion bzw. wann committed wird !!

Vergesse ich nämlich nach vollendeter Eingabe zu committen, gebe noch 10 Rechnungen ein und dann die eine falsche, dann geht das nicht mehr so einfach. Ein Rollback würde nicht nur die falsche rückgängig machen, sondern auch die richtigen !!

Und aus solcherlei Gründen sollte man auch immer die Transactions möglich kurz halten. Die Lesevorgänge getrennt von den schreibenden in Transactions zu kapseln ist auch gut. Allerdings ist es nur echt wichtig, falls jemand DBgrids usw. für Anzeige- und für Eingabezwecke verwendet.

[Jelly]

Zitat von HaJo:

Aber was Transaktionen sind und wie man sie benutzt ist mir äusserst suspekt.

Transaktionen machen eigentlich nur wirklich Sinn, wenn es sich um Mehrbenutzersysteme handelt. Paradox und co. sind dafür z.B. eh nicht ausgelegt, deshalb gibt es da auch keine Transaktionen. Alles, was in Paradox zur DB geschickt wird, wird auch sofort reingeschrieben.

Transaktionen werden gestartet. Anschliessend können Änderungen an den Datenbankrecords gemacht werden, soviele wie nötig. Erst durch ein Commit werden diese Änderungen auch für die anderen User in der DB sichtbar, rsp. durch ein Rollback werden die Änderungen komplett verworfen. In der Session, wo du eine Transaktion startest, siehst du auch sofort die Änderungen. Fügst du also einen Datensatzu ein, ist der für dich auch gleich sichtbar, für die anderen im Netz nicht.

Nicht alle Datenbanksysteme unterstützen Transaktionen, auch nicht wenn sie als Aushängeschild Mehrbenutzerfähigkeit haben. Ich brauch da nur MySQL zu nennen. Lediglich der Tabellentyp InnoDB bietet Transaktionen an, der Standardtyp und auch der einzige, der in der Anwendung keine Lizenzen erfordert, ist MyIsam. Aber das nur am Rande. Alle Großen (Oracle, MSSQL...) unterstützen selbstverständlich Transaktionen.

[MagicAndre1981]

Zitat von Jelly:

Zitat von HaJo:

Aber was Transaktionen sind und wie man sie benutzt ist mir äusserst suspekt.

Transaktionen machen eigentlich nur wirklich Sinn, wenn es sich um Mehrbenutzersysteme handelt. Paradox und co. sind dafür z.B. eh nicht ausgelegt, deshalb gibt es da auch keine Transaktionen. Alles, was in Paradox zur DB geschickt wird, wird auch sofort reingeschrieben.

Nicht alle Datenbanksysteme unterstützen Transaktionen, auch nicht wenn sie als Aushängeschild Mehrbenutzerfähigkeit haben. Ich brauch da nur MySQL zu nennen.

Da muss ich dir aber ein wenig widersprechen. Transaktionen machen auch auf Einzelbenutzersystemen Sinn. Es gibt Fälle in denen mehere Tabellen aktualisiert werde müssen. Hier setzen Transaktionen an. Nur wenn alle Updates erfolgreich waren werden, die Änderungen in die DB geschrieben, sonst muss man ein Rollback machen und Unstimmigkeiten zu vermeiden.

MySQL kann ab Version 4.x (ich weiss die genaue Version nicht) Transaktionen.

MfG
André

[Jelly]

Zitat von MagicAndre1981:

Transaktionen machen auch auf Einzelbenutzersystemen Sinn. Es gibt Fälle in denen mehere Tabellen aktualisiert werde müssen. Hier setzen Transaktionen an. Nur wenn alle Updates erfolgreich waren werden, die Änderungen in die DB geschrieben, sonst muss man ein Rollback machen und Unstimmigkeiten zu vermeiden.

Dem stimm ich zu, ja.

Zitat von MagicAndre1981:

MySQL kann ab Version 4.x (ich weiss die genaue Version nicht) Transaktionen.

Ja, wie ich ja auch geschrieben hab. Aber nur beim Tabellentyp InnoDB, und der kostet Lizenzgebühren.