Hi,
es geht indirekt um dieses Thema:
http://www.delphipraxis.net/internal...9cd23fdac28622
Ich habe das wichtigste rauskopiert, damit nicht jeder alles lesen muß, was hier mit dem Thema nichts zu tun hat:
Zitat von
urs.liska:
Transaktionen sollten so kurz wie möglich sein. Also nicht beim Öffnen des Fensters starten und beim Schließen beenden. Die Transaktion sollte vor Beginn des zusammenhängenden Vorgangs gestartet und nach Abschluss desselben beendet werden. Sie dient nur dazu, zu garantieren, dass die zusammenhängenden Buchungen nicht nur teilweise durchgeführt werden. Transaktionen sind nicht dazu da, bei Datenbanken so etwas wie ein "Dokument" zu simulieren, das erst am Ende der Sitzung gespeichert wird! Wenn Dir das wichtig ist, solltest Du so etwas wie einen Log-Mechanismus verwenden, der alle Änderungen während der Sitzung speichert, um diese ggfs. rückgängig machen zu können. Im Prinzip geht das auch mit Cached Updates oder ClientDataSets...
Zu viele offene Transaktionen können eine
DB natürlich vor allem im Netztwerk schon belasten. Das ist klar, aber es geht mir mehr um den sinnvollen Einsatz derselben. Was er meint ist folgendes, bitte korrigieren, wenn falsch:
Bei einer Rechnung hat man bspw. mehrere Tabellen zu beachten. Rechnungspositionen, Lagerbestand, diverse Statistik-Tables usw., also schon etwas an Aufwand. Jetzt gibt man eine Mengenposition ein und das Programm speichert die ab. Sagen wir mal 10 Tabellen sind davon betroffen. 5 sind fertig und der Server stürzt ab. Dann weiß man ja überhaupt nicht mehr wo man anfangen soll. Am besten rollt man also die ganze Transaktion komplett zurück und fängt neu an.
Jetzt die Hauptfrage:
Dieses Verfahren ließe sich auch hervorragend dazu benutzen, das auf die ganze Rechnung anzuwenden (mit 1 einzigen Transaktion). Also 10 Positionen werden eingegeben, die übliche Kaffeepause, dann weitermachen, aber sobald die Tasse auf dem Tisch steht wieder Absturz. ODER aber: Rechnung wurde komplett eingebenen auf falschen Kunden, kurzerhand Rollback (gesteuert). Das würde dann heißen: übermäßig lange Transaction. Für so was dürfte Urs den "Log-Mechanismus" gemeint haben. Dazu habe ich aber überhaupt keine Idee.
Genauso wenig, was in dem Zusammenhang mit CashedUpdates und ClientDataSet gemeint ist. Wozu soll das gut sein ?
Und dann noch automatische Transaktion. Raff ich auch nicht.