AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Dataset.Next | sehr langsam

Dataset.Next | sehr langsam

Ein Thema von Dekras12 · begonnen am 22. Jan 2019 · letzter Beitrag vom 23. Jan 2019
Antwort Antwort
Seite 4 von 4   « Erste     234
Dekras12

Registriert seit: 22. Jan 2019
11 Beiträge
 
#31

AW: Dataset.Next | sehr langsam

  Alt 22. Jan 2019, 15:03
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!

Geändert von Dekras12 (22. Jan 2019 um 15:38 Uhr)
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.172 Beiträge
 
Delphi XE4 Professional
 
#32

AW: Dataset.Next | sehr langsam

  Alt 22. Jan 2019, 15:44
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.
Heiko
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.575 Beiträge
 
Delphi 2010 Enterprise
 
#33

AW: Dataset.Next | sehr langsam

  Alt 22. Jan 2019, 19:50
@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.
Gruß, Jo
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.172 Beiträge
 
Delphi XE4 Professional
 
#34

AW: Dataset.Next | sehr langsam

  Alt 22. Jan 2019, 20:28
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.
Heiko
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.575 Beiträge
 
Delphi 2010 Enterprise
 
#35

AW: Dataset.Next | sehr langsam

  Alt 23. Jan 2019, 10:13
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.
Gruß, Jo
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.172 Beiträge
 
Delphi XE4 Professional
 
#36

AW: Dataset.Next | sehr langsam

  Alt 23. Jan 2019, 12:07
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
Heiko
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.172 Beiträge
 
Delphi XE4 Professional
 
#37

AW: Dataset.Next | sehr langsam

  Alt 23. Jan 2019, 16:45
Hallo,
und hier geht es weiter, weil das Thema etwas weitergeht

https://www.delphipraxis.net/199437-...ml#post1423964
Heiko
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:57 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf