Dataset.Next | sehr langsam

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