Dataset.Next | sehr langsam

[Delphi.Narium]

@jobo: Meine Antwort war nicht als Kritik an Deinem Vorschlag gemeint. Dein Vorschlag ist ok und so umsetztbar und absolut sinnvoll. Wollte damit nur sagen, dass gegen Deinen Vorschlag nichts, aber auch garnichts einzuwenden ist Ok. Muss wohl an meinen Formulierungen feilen

@hoika:

Natürlich ist ein Execute-Block keine Transaktion, man sollte selbstverständlich vor dem Aufruf des Blockes eine Transaktion starten und beim Beenden mit Commit schließen. Im Fehlerfalle macht man ein Rollback.

TTable ist BDE, das ist mehr als nur Schnee von gestern.

Wir reden hier von FireBird und FireDac. Die sind "geringfügig" neuer. Und TTable war und ist nicht zwingend unidirectional. (Das mag irgendwann mal zu BDE-Zeiten mit der damaligen Version von Interbase so gewesen sein, weiß ich nicht, bei dBase, Paradox ... war's nicht der Fall.) Bei manchen Datenbankkomponenten kann man das aber (z. B. im Objektinspektor) gezielt auswählen.

Und natürlich ist es klar, dass ich auf Datenbankseite für eindeutige Werte eine entsprechende Regel einbaue. Unique-Index wäre da eine durchaus sinnvolle (beinahe zwingend erforderliche) Regel.

Und ggfls. muss eine Transaktion über die gesamte Bearbeitungszeit eines Auftrages laufen und nicht nur für die Dauer der Änderung der Ordnungsnummer. Das kommt (wie jobo richtig anmerkt) auf die Fachlichkeit an.

[jobo]

Zitat von Delphi.Narium:

@jobo: Meine Antwort war nicht als Kritik an Deinem Vorschlag gemeint. Dein Vorschlag ist ok und so umsetztbar und absolut sinnvoll. Wollte damit nur sagen, dass gegen Deinen Vorschlag nichts, aber auch garnichts einzuwenden ist Ok. Muss wohl an meinen Formulierungen feilen

@hoika:
Natürlich ist ein Execute-Block keine Transaktion, man sollte selbstverständlich vor dem Aufruf des Blockes eine Transaktion starten und beim Beenden mit Commit schließen. Im Fehlerfalle macht man ein Rollback.
..

Zunächst, ich habe es nicht als Kritik aufgefasst, vielleicht muss ich auch die Feile rausholen...

Zum Thema Transaktion:
Aus Sicht der Datenbank ist alles eine Transaktion, die ist nämlich per Definition dafür verantwortlich, dass nichts anbrennt. Und dabei ist es ihr auch sch.. egal, was der Client macht. Es muss ihr egal sein, die DB ist der Server und der Client der Client.
Wenn ich also ein einzelnes Updatestatement absetze oder einen anonymen Block laufen lasse (der meinetwegen 5 Minuten für ganz viele Updates und Inserts braucht), beides ist jeweils eine Transaktion und funktioniert entweder oder es funktioniert nicht. Demzufolge ist unabhängig von meiner Clientprogrammierung die Sache am Ende erledigt oder es steht wieder alles auf Anfang.
Ich brauche demzufolge keine Clienttransaktion, sondern eher ein Errorhandling um die Anwenderkommunikation und Programmdarstellung gerade zu ziehen.

Ein anonymer Block wie im Beispiel, mit 2 Statements, die zusammen wahrscheinlich weniger als 0.5 Sekunden brauchen(-je nach Indizierung und update Kriterien), ist die beste Möglichkeit, Ressourcen zu schonen, Dead Locks zu vermeiden und einfach schnell zu sein. Ursache und Wirkung sind dabei austauschbar, denn es ist naheliegend, dass viele User, deren Statements sich verkürzen, sich gegenseitig weniger im Weg stehen mit ihren Transaktionen.

Ich würde noch weiter gehen und sagen, explizite Transaktionskontrolle im Client ist böse, aber dafür kann man bei Interesse ein neuen thread aufmachen.

[hoika]

Hallo,

Zitat:

Ich brauche demzufolge keine Clienttransaktion

Oha, Einspruch.

Bsp 1
Wir laden einige Daten aus der DB, ein paar Selects, ein paar SPs, dumdidum
Ohne Client-Transaktion wird jede Abfrage in einer separaten Transaktion auf der DB gestartet
und das kostet eine Menge Performance.


Bsp 2 (OK, etwas konstruiert):
Ich habe 3 SPs, die ja nach Konfiguration nacheinander aufgerufen werden müssen.
SP1->SP2->SP3
oder SP1->SP3

Aber in genau einer Transaktion.
Und die Konfiguration kennt nur der Client.
Woher soll die DB wissen, dass alles in einer Transaktion laufen soll.

[jobo]

Zitat von hoika:

Oha, Einspruch.
..

zu Bsp 1
Eine Transaktion an sich frisst kein Brot (tatsächlich frisst sie doch welches, aber unsereiner wäre mit dem bisschen auf Extremdiät)
Zum Ausprobieren eignen sich die berühmten "ganz vielen Datensätze", die man importieren muss.
Macht man ein Commit per SQL nach jedem einzeln Insert Statement, dauert es etwas länger, als wenn man bspw. nur alle 1000 oder 10000 Datensätze ein Commit macht. (Am besten man macht nur eins, am Ende)
Unabhängig von Art und Programmierung des Clients, für den Server ist sowieso alles immer in einem Transaktionskontext. Das läuft ständig mit.

zu Bsp 2
Die Konfiguration, die nur der Client kennt (und ich nehme mal an, gemeint ist: per Client Transaktion erzwingt), ist ein fachlicher, logischer Zusammenhang in dem eine Datenverarbeitung ablaufen soll. Das ist erstmal okay, es produziert aber overhead, den man gerne vermeiden will.

Nehmen wir SP1> SP3 und stellen uns vor, es sei das Update und Insertstatement aus dem Thread hier. Natürlich soll das in einer Transaktion laufen, das eine ohne das andere macht keinen Sinn.
Dazu kann ich nun eine Clienttranskation nehmen, die das ganze "aus der Ferne" aufruft und "künstlich" kapselt. Fall erledigt, ich muss mich aber auf die Implementierung und Nachteile von Clienttransaktionen verlassen (hängt von RDBMS, Client und Compos ab)
Ich kann aber auch einen anonymen Block drum legen und das vom Client als ein einziges Statement auf dem Server ausführen lassen. Es ist damit automatisch eine (1, EINE) Transaktion.
Für die 2. Methode zahle ich idR. einen geringeren Preis, weil der Server selbst besser und schneller arbeitet, als die zusätzlichen Module im Client.

Zitat:

Woher soll die DB wissen, dass alles in einer Transaktion laufen soll.

Eben, sie weiß es nicht, außer:
ich mache daraus eine eigene SP oder einen anonymen Block, fertig.

[hoika]

Hallo,
Hm, eigener Thread ?

Ich habe 10 SPs, die je nach Konfiguration nacheinander aufgerufen werden müssen in einer einzigen Transaktion.
SP1->SP2->SP3->SP6->SP10
oder
SP1->SP3->SP9->SP6
oder
SP10->SP8->SP6
oder oder oder

Und jetzt bei mal pro möglicher Konfiguration eine SP, viel Spass.
Waren das 10! (Fakultät) Möglichkeiten?

Wahrscheinlichkeit hatte ich echt ne richtig verstanden

[hoika]

Hallo,
und hier geht es weiter, weil das Thema etwas weitergeht

https://www.delphipraxis.net/199437-...ml#post1423964