@peterbelow
Wow ! Top Erklärung besten Dank!
Wenn nun zwei Transaktionen auf die gleiche Tabelle offen sind und beide User ändern den gleichen Datensatz werden die daten einfach überschrieben ist dies korrekt ?
Also die zuletzt geschriebenen Daten sind dann in der
DB.
QryUser1.Open;
QryUser2.Open;
QryUser1.Edit (In Feld 'ABC' wird '500' eingetragen)
QryUser2.Edit (In Feld 'ABC' wird '600' eingetragen)
QryUser1.Post;
QryUser2.Post;
QryUser1.Close;
QryUser2.Close;
Was ist nun im Feld 'ABC' eingetragen ? '600' richtig ?
Macht es nun einen unterschied wer die Transaktion zuerst schliesst(qry.close)? (Laut deiner erklärung Ja.)
Wird mit dem Post in die Memory-Transaktion des Servers geschrieben oder direkt auf die
DB ?
Mfg Int3g3r
Das clientseitige Framework kompliziert die Sache erheblich und macht das Ganze undurchsichtig, was das Verständnis erschwert. Wenn man direkt mit
SQL arbeitet ist Sequenz der Ereignisse deutlich einfacher zu erkennen. Zuerst mal ist die Abfrage nicht direkt mit dem Update eines Datensatzes verknüpft. Das sieht nur so aus, weil das Client-Framework so konstruiert ist. Was aber auf der
SQL-Ebene passiert sind zwei völlig separate Aktionen, die auch normalerweise in verschiedenen Transaktionn abgewickelt werden.
Vereinfacht macht das Framework in etwa folgendes:
Abfrage:
SELECT <fieldlist> FROM tablename WHERE condition1;
Update:
try
UPDATE tablename SET field1 = value, field2 = value ....
WHERE condition2;
COMMIT;
except
ROLLBACK;
raise
end;
Der Knackpunkt ist hier folgender: condition1 liefert normalerweise eine ganze Reihe von Zeilen zurück. Für das UPDATE muss condition2 aber so formuliert sein, das damit exakt
eine Zeile in der Tabelle identifiziert wird, nämlich die, die der Benutzer gerade editiert hat. Die einzig generelle Methode, das zu machen (und gleichzeitig die am wenigsten effiziente) ist es, einfach für alle nicht-LOB Felder in der WHERE-Klausel eine Bedingung der Art feld = orginalwert anzugeben. Damit findet der Server den zu ändernden Record nur, wenn er noch nicht von einem anderen Benutzer geändert wurde. Wenn der Record nicht gefunden wird gibt der Server zurück, dass 0 Records geändert wurden, der Client erzeugt daraufhin eine
Exception, und (bei automatischen Transaktion-Handling) die Transaktion wird zurückgerollt.
Wenn 2 Clients also parallel den gleichen Datensatz bearbeiten gewinnt der, der zuerst das COMMIT ausführt. Erst dann wird der vom UPDATE-Statement erzeugte Datensatz aus der Transaktion der Session in die Datenbank geschrieben.
Wie parallele Transaktionen sich auswirken hängt maßgeblich davon ab, wie die WHERE-Klausel des UPDATE-Statements aufgebaut wird. Im Prinzip kann man da z. B. nur den primary key des Datensatzes verwenden. Da sich der aber nie ändert würde man damit aber Kollisionen zwischen Transaktionen nicht erkennen, dann würde das zweite COMMIT eventuell Änderungen des ersten überschreiben. Wenn man das vermeiden will und trotzdem effiziente UPDATEs haben will erfordert das mehr Arbeit, z. B. eine Versionnummer in einem Feld der Tabelle, die nach jedem Update automatisch von einem Trigger hochgezählt wird. Dann kann man die Kombination primary key + Versionsnummer verwenden, um den Datensatz auszuwählen und hat trotzdem eine effiziente Kollisionsdetektion. Nachteil: man muss die Versionsnummer nach dem Update in der clientseitigen Version aktualisieren. All das in diesem Absatz kannst Du im Prinzip vergessen, wenn Du mit data-bound controls und einem der mit Delphi gelieferten data
access frameworks arbeitest, da hat man einfach nicht genug Kontrolle über die Details.