FireDac ODBC Query bringt alte Daten

[fisipjm]

Zitat von Frickler:

Zitat von fisipjm:

Wann endet ein Transaktion bei Firedac (Firebird?) Ich mache ja breits ein Open/Edit/Post/Close und bei der anderen Query ebenfalls ein Open/Close.

Bei Firebird müssen Transaktionen explizit committed werden. Wird einfach die Verbindung geschlossen (Programm beenden), hängt es von den Datenbankkomponenten ab, ob das ein Commit oder Rollback wird.
Erst in Firebird 4 gibt es auch von der Datenbankseite die Möglichkeit, AutoCommit zu konfigurieren.

AutoCommit wäre in diesem Fall aber auch falsch. Was ist denn, wenn zwischen "HolDieNummer" und "SetzDieNummer" jemand anders die Nummer erhöht? Da müsste "SetzDieNummer" als 3. Parameter den vorherigen Wert der Nummer abfragen. Also nur erhöhen, wenn zwischendurch niemand anders erhöht hat.

P.S.: warum nicht alles in einem Rutsch?

Code:

UPDATE nummernkreise SET zaehler = zaehler + 1
WHERE Spalte1 = :Kriterium1 and Spalte2 = :Kriterium2
RETURNING OLD.zaehler

(vorausgesetzt, das geht mit ODBC)

Gute Punkte. Zum Thema wenn jemand dazwischend eine Nummer holt. Ja, in der Theorie möglich, in der Praxis spielt sich die Abarbeitung im Millisekunden Bereich ab.
Gute Idee mit der Update und Retruning methode, allerdings muss ich die Nummer noch in eine andere Tabelle schreiben und darf die Nummer in den Nummernkreisen erst updaten wenn das Schreiben auch tatsächlich funktioniert hat.

Was ich nicht verstehe ist, ein Commit betrifft doch normal nur das Updaten. Das Updaten funktioniert aber, alleine die Select abfrage zum abrufen holt den alten wert. Der neue Wert steht zu dem Zeitpunkt aber definitiv schon der Datenbank. Ich glaube also nicht das es an dem Commit liegt.

[Frickler]

Zitat von fisipjm:

Was ich nicht verstehe ist, ein Commit betrifft doch normal nur das Updaten. Das Updaten funktioniert aber, alleine die Select abfrage zum abrufen holt den alten wert. Der neue Wert steht zu dem Zeitpunkt aber definitiv schon der Datenbank. Ich glaube also nicht das es an dem Commit liegt.

Bei Firebird müssen auch SELECTs committed werden (oder ein Rollback).

Wenn Du gar keine Transaktionsanweisungen verwendest, passiert folgendes: beim Starten des Programms öffnet die Verbindungskomponente eine Transaktion. Und die ist dann so lange offen, bis Du sie explizit committest, oder die Verbindung wieder schließst. Da hängts dann von den Einstellungen ab, ob ein Commit oder Rollback ausgeführt wird. Viele Verbindungskomponenten bieten eine Property "AutoCommit", mit der wird jedes Select und jede andere Anweisung automatisch committed. Damit sich Select-Fenster dann nicht einfach schließen, ist das kein normaler Commit, sondern ein sog. CommitRetaining. Das heißt, es wird committed und danach sofort eine neue Transaktion gestartet.

Jetzt wird auch klar, warum "HolDieNummer" niemals die neue Nummer holt - weil Du Dich immer in der gleichen Transaktion bewegst, und Firebird kein "Dirty Read" (uncommittete Daten anzeigen) beherrscht.

[fisipjm]

Zitat von Frickler:

Zitat von fisipjm:

Was ich nicht verstehe ist, ein Commit betrifft doch normal nur das Updaten. Das Updaten funktioniert aber, alleine die Select abfrage zum abrufen holt den alten wert. Der neue Wert steht zu dem Zeitpunkt aber definitiv schon der Datenbank. Ich glaube also nicht das es an dem Commit liegt.

Bei Firebird müssen auch SELECTs committed werden (oder ein Rollback).

Wenn Du gar keine Transaktionsanweisungen verwendest, passiert folgendes: beim Starten des Programms öffnet die Verbindungskomponente eine Transaktion. Und die ist dann so lange offen, bis Du sie explizit committest, oder die Verbindung wieder schließst. Da hängts dann von den Einstellungen ab, ob ein Commit oder Rollback ausgeführt wird. Viele Verbindungskomponenten bieten eine Property "AutoCommit", mit der wird jedes Select und jede andere Anweisung automatisch committed. Damit sich Select-Fenster dann nicht einfach schließen, ist das kein normaler Commit, sondern ein sog. CommitRetaining. Das heißt, es wird committed und danach sofort eine neue Transaktion gestartet.

Jetzt wird auch klar, warum "HolDieNummer" niemals die neue Nummer holt - weil Du Dich immer in der gleichen Transaktion bewegst, und Firebird kein "Dirty Read" (uncommittete Daten anzeigen) beherrscht.

Saubere Erklärung, vielen Dank, wieder was gelernt.