Dataset.Next | sehr langsam

[Dekras12]

Bei diesen Programm arbeiten nur 3 Personen und die würden niemals im gleichen Auftrag etwas bearbeiten und diese sind dann bei 14 Tagen unbearbeitbar. Ich muss nur halt den Code anpassen wie z.B. falls ich etwas Lösche ... z.B. muss ich nicht mehr die aktuelle Zeilennummer nehmen sondern die Ordnung der ausgewählte Zeile entnehmen. Falls die Ordnung Leer ist, muss ich einmalig noch die alte Funktion nehmen (geht um alte Einträge).

Ihr alle habt mir sehr geholfen ... vielen Dank!

[hoika]

Hallo,
gut, das es jetzt etwas schneller läuft.
Versuche noch mal einen normalen (Asc) Index auf die Artikelnummer zu setzen.

Der Desc-Index wird nicht zum Suchen/Filtern benutzt.
Wenn es nichts bringt, kannst du ihn ja mir Drop Index wieder entfernen.

Nach solchen DB-Aktionen immer das auch das Programm neustarten.

[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