Dataset.Next | sehr langsam

[Dekras12]

Embarcadero® Delphi XE7 Version 21.0.17707.5020

Moin Leute,

ich habe bisher keine große Erfahrung mit Delphi (Pascal). Ich habe die Aufgabe bekommen ein altes Programm auf den neusten Stand zu bringen und bitte um eure Unterstützung

Ich habe bemerkt das DataSet.Next ziemlich langsam ist. Ich habe eine Tabelle, die mit der Datenbank verbunden ist und wenn ich eine neue Zeile hinzufüge dann braucht er, abhängig wie viele Zeile er hat, in diesen Fall z.B. 50 Zeilen, braucht er für eine neue Zeile so 2-3 Sekunden.

Diese Funktion wird auch bei einem Button wo der kompletter Auftrag kopiert wird und neu erstellt wird mit einer neuer Vorgangs ID. Ich habe es so geregelt das ich es alles über einer Query gemacht habe. Ich habe es mit Insert + Select gemacht.


Resultat
Alte Geschwindigkeit: 4 min
Neue Geschwindigkeit: 1-2 Sekunden

Nur leider kann ich es bei der Funktion "Zeile hinzufügen" nicht einsetzen. Da er eine Spalte mit den Namen "Ordnung" hat. Die ist dafür da um die Daten zu sortieren in der Tabelle, weil es so gewollt ist, das man auch zwischen der Zeilen bei der Tabelle eine neue Zeilen hingezufügt werden kann und nicht nur am Ende.

Ist sowas überhaupt möglich ohne das ich mit der Funktion Dataset.Next arbeite?

Before Update

ID	Value 1	Value 2	Value 3	Ordnung
1	A	B	C	0
1	A	B	C	0
1	A	B	C	0
1	A	B	C	0

After Update

ID	Value 1	Value 2	Value 3	Ordnung
1	A	B	C	1
1	A	B	C	2
1	A	B	C	3
1	A	B	C	4

Code:

//Zeuerst wird die neue Zeile erstellt
         try
  try

               FDQuery21.Close;
               FDQuery21.ParamByName('Qs_0').AsInteger := daten.pos.fieldbyname('AUFNR').asinteger;
               FDQuery21.ParamByName('Qs_1').AsString := Z_ARTNR;;
               FDQuery21.ParamByName('Qs_2').AsString := Z_EINHEIT;
               FDQuery21.ParamByName('Qs_3').AsCurrency := Z_MENGE;
               FDQuery21.ParamByName('Qs_4').AsCurrency := Z_ZU1;
               FDQuery21.ParamByName('Qs_5').AsCurrency := Z_EK;
               FDQuery21.ParamByName('Qs_6').AsCurrency := Z_EP;
               FDQuery21.ParamByName('Qs_7').AsCurrency := Z_GP;
               FDQuery21.ParamByName('Qs_8').AsString := Z_TEXTZEILE;
               FDQuery21.ParamByName('Qs_9').AsCurrency := Z_EKEURO;
               FDQuery21.ParamByName('Qs_10').AsCurrency := Z_EPEURO;
               FDQuery21.ParamByName('Qs_11').AsCurrency := Z_GPEURO;
               FDQuery21.ParamByName('Qs_12').AsInteger := z_AktuellerStand;              //AktuellerStand ist die aktuelle Zeile die in der Tabelle ausgewählt wurde         
               FDQuery21.ParamByName('Qs_14').AsString := 'N';
               FDQuery21.Open;

       except
    on e: Exception do

  end;
finally
  Ini.Free;
end;





        z_a := 1;
         daten.pos.First;

         while not daten.pos.eof do begin
         
if z_a = z_AktuellerStand  then //Falls der Zähler = Wert der aktuell gewählte Zeile
         
begin

               
       
try
       
try
             
              z_a := z_a + 1; //Hier wird übersprungen, weil die neue Zeile die Zahl für die Ordnung hat
            



             FDQuery24.Close;
             FDQuery24.ParamByName('qs_0').AsInteger := ValueFieled0.AsInteger; //Auftragsnummer
             FDQuery24.ParamByName('os_1').AsInteger := z_a; //Zahl für die Ordnung
             FDQuery24.Open;




      
 except
      
 on e: Exception do

      
 end;
     
 finally
      
 Ini.Free;
      
 end;


              z_a := z_a + 1;
              daten.pos.next;

 end




 else
 begin


  try
  try




          FDQuery24.Close;
          FDQuery24.ParamByName('qs_0').AsInteger := ValueFieled0.AsInteger;
          FDQuery24.ParamByName('os_1').AsInteger := z_a;
           FDQuery24.Open;




  except
  on e: Exception do

  end;
 finally
  Ini.Free;
 end;



                z_a := z_a + 1;
                daten.pos.next;
  end;
  end;




    daten.pos.Refresh;

Lösung:

Code:

UPDATE Table
SET    ORDNUNG = CASE 
                        WHEN ORDNUNG >= :QS1 THEN ORDNUNG + 1                        
                        ELSE Ordnung
                    END 
WHERE AUFNR = :QS2

[Delphi.Narium]

Mir ist nicht klar, wozu Du DataSet.Next benötigst.

Zum Anhängen neuer Datensätze nutzt man eher DataSet.Append oder zum "Einfügen irgendwo mittendrinne" DataSet.Insert.

Mit DataSet.Next scrollt man zum nächsten, vorhandenen Datensatz.

Zeig' mal bitte den fraglichen Quelltext, so dass man besser sehen kann, was Du genau meinst.

[jobo]

Was genau ist das Problem?
Wenn die "Ordnung" beizubehalten ist, müssen nachfolgende Datensätze entsprechend aktualisiert werden oder mit geschickt gewählten Zwischenwerten (float) gearbeitet werden.

Das langsame Einfügen scheint mir aber verdächtig. Und was ist z.B. 50? 50 Datensätz in der Tabelle? 50 Datensätze als Ergebnis einer Abfrage (aus 500T datensätzen)?
Vielleicht kannst Du das noch erläutern. Das dürfte für alle Helfer wichtige Hinweise liefern.
Welche Komponenten und welche DB sind auch spannende Infos.

[Dekras12]

• 50 Datensätze als Ergebnis einer Abfrage (aus ~ 400T Datensätzen)

• Der Code sieht unüberscihtlich aus

[Edit]
Wenn ich die daten.pos.next verwende. Dann zieht man bei der Tabelle das er zu jede einzelne Zeile durchgeht und das dauert bei 50 Datensätze. Das ist so ob, er jeden Datensatz auswählt.

[Delphi.Narium]

Bei 400T Datensätzen kann das Scrollen schon mal dauern, wenn es keinen Index für irgendeine Ordnung der Daten gibt. Und soll dann per Next ein Datensatz eingefügt werden, so wird (schlimmstenfalls) ein Fulltablescan gemacht, um zum letzten Datensatz zu gelangen und dann einen neuen dranzuhängen. Das ist suboptimal.

Zitat:

Der Code sieht unüberscihtlich aus

Das ist irrelevant. Ohne den auch nur ansatzweise zu kennen, ist es annähernd unmöglich Dir irgendwelche zielführenden Tipps zu dem konkreten Problem zu geben.

Entweder den Code verbessern und dann hier posten oder damit leben, dass wir uns dadurch wurschteln müssen. Eventell liegt die Ursache des Problems ja auch am unübersichtlichen Code und man kann quasi mit 'ner Umstrukturierung auch das Problem beheben ;-)

[jobo]

Zitat:

Zitat von Dekras12 (Beitrag 1423841)

Wenn ich die daten.pos.next verwende. Dann zieht man bei der Tabelle das er zu jede einzelne Zeile durchgeht und das dauert bei 50 Datensätze. Das ist so ob, er jeden Datensatz auswählt.

Wer woll denn wissen was daten.pos.netxt macht und welche Ereignisse dabei noch behandelt werden? Ohne konkreten Code, Eventroutinen etc. ist keine Unterstützung zu leisten. Alles nur Kaffeesatz Leserei.

Ein 50 Rekords großes Ergebnis einer Query müsste eigentlich schnell navigierbar sein. Außnahmen gäbe es diverse, je nach Ereignisbehandlungsroutinen, die am Scrollen dran hängen.

[Dekras12]

daten.pos ist ein FDQuery und sein SQL Text ist:

Code:

SELECT * From TABLE WHERE AUFNR = :QS1 Order by Ordnung

Die FDQuery ist verbunden mit der Tabelle. Die Tabelle wird dan per Ordnung sortiert. Wenn man auf "Zeile einfügen" drückt, dann erstellt er zuerst die neue Zeile mit den default Eingaben.
Dann wird mit die erste Zeile von daten.pos aufgerufen und von da aus erstellt für jede Zeile einen neue Ordnungsnummer. Falls er mit der neue Zeile kommt, dann soll er die Ordnung nochmal +1 machen.

Ich versuche den Code verstänldich zu gestalten

[mkinzler]

Existiert ein adäquater Index über AufNr und Ordnung?

[jobo]

Ok, wenn das alles mit den visuellen Komponenten geschieht, auch das next und dann das Update x 50 datensäte, dann ist es offensichtlich langsam. Wahrscheinlich würde schon ein deaktiviren der GUI etwas helfen.

Ich denke, ein pures Insert, gefolgt von dem Update für die "Ordnung" kann das sicher auf <1Sekunde beschleunigen.

[Dekras12]

*Doppelter Eintrag*

[Dekras12]

Ich habe es mir auch gedacht, aber das hat nicht geholfen.
Ich habe es mit rxdbgrid2.DataSource.DataSet.DisableControls deaktiviert. War etwas besser, aber nicht gut genug.
Früher hat es auch geklapt, aber das Programm wurde auf das neue Delphi konvertiert, wie ich es verstanden habe

[Jumpy]

Ich würde auch per SQL die Ordnung aller betroffenen Datensätze (die größer (gleich) der Insert-Stelle) sind erhöhen. Dann den neuen Satz einfügen und dann ein refresh der Query.

[Dekras12]

@Jumpy Ich probiere es mal aus
@mkinzler Was ist ein adäquater Index?

[Delphi.Narium]

Gibt es einen Index auf die Spalte AufNr oder zumindest einen, der diese Spalte an erster Stelle enthält?

Ansonsten muss die Datenbank beim Scrollen per Fulltablescan jeweils den nächsten Satz, der die Bedingung erfüllt, suchen und das kann dauern.

[mkinzler]

Zitat:

@mkinzler Was ist ein adäquater Index?

Am Besten einen über diese beide Spalten.

[hoika]

Hallo,#
zumindestens das normale DBGrid war zwar sehr clever, wenn es sich im DBase/Paradox handelte,
aber bei Interbase/Firebird nicht ganz so.
Indizes waren extrem wichtig und zwar Indizes in beiden Richtungen
(Create Asc Index, Create Desc Index).
Das Asc kannst du auch weglassen.

Ansätze
1. Nimm eine leere Datenbank bzw. eine mit wenigen Datensätzen.
Ist das dort schnell, musst Du dir die SQL-Befehle ansehen,
die das DBGrid so wegschickt (DB-Monitor benutzen).

2. Bau doch mal testweise das gleiche mit einem TStringGrid oder einem normalen RXGrid nach
(dann natürlich nur mit Queries).

[hoika]

Hallo,

Delphi-Quellcode:

daten.pos.First;
         while not daten.pos.eof do begin

Was konkret machst du hier?
Kann es sein, dass die date.pos deine 400K Tabelle ist und du versuchst,
das Feld Ordnung so zu setzen, dass der neue Tabelleneintrag zwischen 2 anderen liegt?

geg:
Record2000, Ordnung-2000
Record2001, Ordnung-2001

Ziel
Record2000, Ordnung-2000
Record_neu, Ordnung-2001
Record2001, Ordnung-2002

[Dekras12]

@hoika Ja du hast es richtig verstanden.


[Edit] Es ist gut möglich, das die keinen Index haben. Ich kenne mich noch nicht mit Index aus, aber ich werde mich erstmal durchlesen. Vielen vilen Dank erstmal für die Hilfe und Vorschläge.

[Edit2] Jetzt verstehe ich das mit den Index, aufnr hatte schon bereits einen Index (Descending).

[mkinzler]

Diese Updates würde ich auch per SQL durchführen:

SQL-Code:

update <Tabelle> set ordnung = ordnung +1 where ordnung > = :id;

[hoika]

Hallo,
siehe mkinzler.
Id ist in meinem Beispiel Record2001, Ordnung-2001

Zuerst das Update, dann das Insert.
Probleme sind aber im Mehrbenutzerbetrieb zu erwarten.

Wenn kein Index angelegt ist, wird es für die DB bitter.
-> 100 mal Full Table Scan (wegen dem DBGrid), und das bei 400K Datensätzen.

Ein (Asc) Index beschleunigt das Suchen erheblich,
verlangsamt aber Insert/Update/Delete.
In der Regel kann man das aber vernachlässigen.

Wenn du ein Order By benutzt, wäre ein (Asc) Index auch schön.
Entscheidend ist aber der Index auf die Artikelnummer.

Create Index idx_TabName_FeldName On TabellenName(FeldName)
idx_TabName_FeldName ist ein Vorschlag, z.B. idx_Artikel_ArtNr

[Dekras12]

Ich werde es sofort alles austesten, vielen Dank

[jobo]

Zitat:

Zitat von hoika (Beitrag 1423866)

Zuerst das Update, dann das Insert.
Probleme sind aber im Mehrbenutzerbetrieb zu erwarten.

Ist das so? Ich würde es so versuchen und habe eine wasserdichte Operation (falls fb tatsächlich anonyme blöcke kann, ist nur gemäß anleitung ohne Garantie):

Code:

execute block
as

begin
  -- neuer Daten inkl Auftragsnummer, Ordnungsnummer usw. ggf
  insert into <theTable> (<fieldlist>) values (<paramlist>);
  update <theTable> 
     set ordnung = ordnung +1
   where auftragsnummer = :paramAuftrNr
     and ordnung > :paramCurrentPos;
end

[Delphi.Narium]

Natürlich kann Firebird anonyme Blöcke und es gibt auch Transaktionen. Da können nicht zwei (oder mehr) gleichzeitig die gleichen Datensätze unterschiedlich ändern!

Und seit vielen Jahren arbeite ich regelmäßig mit DBGrids. Mir ist noch nie aufgefallen, dass die irgendwelche Statements an die Datenbank schicken. Die Verbindung erfolgt immer über TDataSource und dort über die zugeordnete TDataSet-Komponente.

Was beim DBGrid langsam ist, ist die permanente Aktuallisierung der Oberfläche, wenn man in 'ner Schleife durch die Datenmenge scrollt. Aber dafür gibt es DisableControls.

Für sinnvolle Hilfe brauchen wir den fraglichen Quelltext und die vollständige Tabellendefinition. Vermutlich sieht man dann auf den ersten Blick, wo ggfls. was zu ergänzen und/oder umzugestalten ist.

[jobo]

Zitat:

Zitat von Delphi.Narium (Beitrag 1423875)

Natürlich kann Firebird anonyme Blöcke und es gibt auch Transaktionen. Da können nicht zwei (oder mehr) gleichzeitig die gleichen Datensätze unterschiedlich ändern!
..

Ich wollte nur sagen: Es ist eine ungeteste Lösung quasi nach Lehrbuch*, ich nutze Firebird nicht in der Praxis nicht.

Zu meinem eigenen Codevorschlag:
Die Reihenfolge ist tatsächlich besser andersrum, wie hoika schrieb, dann ist das Update der Ordnungszahl "richtiger".

* Damit ist sowohl die Firebird Doku gemeint, als auch der Vorgang an sich, der minimalinvasiv ist, also wahrscheinlich sehr schnell.

Wenn es klappt und verstanden ist (Prinzip), kann man natürlich auch anfangen echte SP für sowas anzulegen statt mit anonymen Blöcken zu arbeiten.

[hoika]

Hallo,
Probleme im Mehrbenutzerbetrieb -> ja

richtiger ist aber nicht richtig ;)

wasserdichte Operation -> = Transaktion, Execute Block ist meines Wissens keine Transaktion.
Das habe ich allerdings noch fast nie benutzt, ich könnte mich also auch irren.

Das meinte ich aber nicht.

Noch mal mein Bsp.
Nutzer 1 beginnt Transaktion 1
geg.
Record2000, Ordnung-2000
Record2001, Ordnung-2001

Ziel
Record2000, Ordnung-2000
Record_neu, Ordnung-2001
Record2001, Ordnung-2002
-> Commit

Nutzer 2, beginnt Transaktion
geg.
Record2000, Ordnung-2000
Record2001, Ordnung-2001

Ziel
Record2000, Ordnung-2000
Record2_neu, Ordnung-2001
Record2001, Ordnung-2002
-> Nutzer 2 Commit

Wenn jetzt der Nutzer2 kurz hinter Nutzer1 beginnt (StartTransaction) und kurz nach Nutzer 1 sein Commit macht.
Was passiert?

Die beiden neuen Records haben die gleiche Ordnungszahl.
Weil beide Transaktionen voneinander getrennt laufen und den gleichen Ausgangsdatenbestand haben.

Record2000, Ordnung-2000
Record_neu, Ordnung-2001
Record2_neu, Ordnung-2001
Record2001, Ordnung-2002

Hier könnte ein Unique Index helfen, so dass zumindestens die Transaktion von Nutzer2 komplett verworfen wird.

[hoika]

Hallo,
Delphi.Narium

Doch, zumindestens war das früher so.
Das TTable-DataSet ist ja unidirectional (es sei, denn es ist ne Query).

Andreas Kosch hatte das mal in einem Interbase-Buch schön auseinandergedröselt.

[Dekras12]

Gut ... es läuft auf jedenfall schneller und ich denke auch ausreichend :-D

Ich habe es auf einer Query gemacht. Ich muss halt noch den Code etwas weiter ändern, weil die Ordnung könnte auf alle Felder auf null sein, aber das wäre kein Problem.

Code:

UPDATE Table
SET     ORDNUNG =  CASE  
                        WHEN ORDNUNG >= :QS1 THEN  ORDNUNG + 1                        
                        ELSE Ordnung
                    END 
WHERE AUFNR = :QS2

Großen Dank an hoika und mkinzler und ich bedanke mich auch bei den anderen dir mir helfen wollten :thumb:

[jobo]

Zitat:

Zitat von Dekras12 (Beitrag 1423879)

Gut ... es läuft auf jedenfall schneller und ich denke auch ausreichend :-D

Prima!

Zu meinem Vorschlag und den Einwänden. Transaktionen laufen nacheinander. Wenn also der Startwert (Parameter) für die Neuberechnung innerhalb der Transaktion gesetzt wird, wäre es kein Problem.

Dann ist wie so oft rein fachlich die Frage, ob es überhaupt Überschneidungen gibt. Also wird wirklich von 2 Sachbearbeitern oder mehr gleichzeitig am gleichen Auftrag gearbeitet? Ja, kann natürlich sein, dann muss man tatsächlich das Problem betrachten. (Da Dekras jetzt schon zufrieden ist, kann es nicht so dramatisch sein)

[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.

[ConnorMcLeod]

Zitat:

Zitat von hoika (Beitrag 1423877)

Die beiden neuen Records haben die gleiche Ordnungszahl.

Und wenn Du Dir die Ordnungszahl von einer stored procedure in der DB liefern läßt? Das wäre dann tatsächlich seriell und deswegen eindeutig.

[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:

Zitat von Delphi.Narium (Beitrag 1423881)

@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:

Zitat von hoika (Beitrag 1423917)

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