Lock conflict on no wait transaction ?

[Hansa]

Jobo, es geht nicht um die Tatsache, dass es Transaktionen gibt. UNd ja, man kann die nicht weglassen. Eine DB braucht eine Transaction und ein Dataset auch usw. und basta. Die "erfinden" sich nicht von alleine eine Transaktion !

Das hier ist allerdings noch wichtig :

Zitat von Blup:

Fall2: Objekt ist jetzt für andere Benutzer gesperrt.
> eventuell zusätzlich oder aktualisierte Daten lesen
> Änderungen vornehmen und Posten
> Commit
> Ende

Vor allem das mit den "aktualisierte Daten lesen". Du meinst ja ungefähr so, oder ?

Delphi-Quellcode:

  DS.Close;
  DS.SelectSQL.Text := 'SELECT * FROM TESTTABLE WHERE NR='+IntToStr (Nr);
  DS.Open;
  if not DS.IsEmpty then begin
    DS.Edit;
//   neu Lesen, wie weiter ????????

Mit 2. Dataset oder wie ? Mir wäre fast folgendes am liebsten. 3 Datasets. Erstens das Original, zweitens das, was gerade bearbeitet wird. Und dann noch vor dem endgültigen speichern ein neu gelesenes. Dann könnte man nämlich auch eventuell doch zwischenzeitlich gemachte Änderungen behandeln. Nur, wie am besten machen ?

[mkinzler]

Wegen der verwendeten Versionierung, sind Transaktionen in Firebird unabdingbar ( Alles läuft in Transaktionen)

[jobo]

Welche Versionierung?
Ich kenne mich mit Firebird nicht aus.
Gibt es da besondere Anforderungen oder Gründe für Transaktionen auf Clientseite?

[Hansa]

Zitat von jobo:

Welche Versionierung?

Wer nicht mal das weiss, für den ist klar :

Zitat von jobo:

Ich kenne mich mit Firebird nicht aus.

Soll jetzt hier etwa einer die absoluten Grundlagen erklären ? In einem Thema, wo es um Mehrplatzsysteme geht oder wie ? Oder wird "lediglich nur" gespammt ?

[mkinzler]

Firebird verwendet keinen Transaktionslog, wie andere DBMS, sondern Datensatzversionierung. Bei einem Update eines DS wird eine neuer DS mit höherer Version erzeugt. Andere Transaktionskontexte sehen aber noch den alten DS. Deshalb müssen auch Selects in Transaktionen laufen, um die richtige Version zu bekommen.

Hansa: Nach Gespamme sehen seine Antworten gar nicht aus.

[jobo]

@markus: Danke, aber ich habe den Clou glaube ich noch nicht ganz verstanden. Geht es um Isolation Level?

Sorry Hansa, dass ich mich ohne tief greifende Firebird Kenntnisse in die Diskussion eingemischt hab.
In meiner Datenbank-Welt ist es immer so, dass ich mich darauf verlasse/ die Datenbank mir garantiert, dass nur ich in meiner Transaktion die geänderten Daten sehe und niemand anders. Wie das garantiert wird, ist mir dabei erstmal egal.

Was die "absoluten Grundlagen" angeht, die werden doch hier täglich vermittelt, oder?

Im übrigen gefällt mir das Forum, weil man hier nicht angemacht wird, wegen des Frageniveaus.

[mkinzler]

Zitat:

@markus: Danke, aber ich habe den Clou glaube ich noch nicht ganz verstanden. Geht es um Isolation Level?

Nein, obwohl dieses damit zusammenhängt.

Es hat damit zu tun, wie der Firebird-Server Transaktionen/Änderungen innerhalb von Transaktionen verwaltet. Die meissten DBMS verwenden hierfür eine Logdatei, in der die Änderungen protokolliet werden; beim Rollback werden dieses dann in umgekehrter Reihenfolge umgekehrt.
Firebird verwendet hier für Versionierung, d.h. es wird beim Update der vorhandene Datensatz nicht geändert, sondern ein neuer mit einer höheren Version erzeugt. Das DBMS verwaltet diese Versionen und welche Version welcher Transaktionskontext sieht. Beim Rollback wird dann nur die Version des Kontext ungültig.

[jobo]

OT:
Mmh, wie gesagt, ich verstehs nicht und es scheint mir um die Technik hinter einer Transaktion zu gehen.
Ich versteh auch nicht, wieso man um ein einziges Insert oder Update eine Clienttransaktion baut.
Aber das ist ja nicht mein Thread.

[Lemmy]

Hi,

ganz einfach: weil da ne Menge schief gehen kann. Vergiss nicht, dass selbst durch ein einfaches Insert ne ganze Menge an Tabellen betroffen sein können (Triggers usw.).

Weiterhin: Wäre doch auch schlecht für dein Bankkonto, wenn die Bank für kleine Überweisungen unter 50€ auch keine Transaktionen einsetzen würde

Grüße