Ich habe mal ein bisschen rumgespielt, und mir mal eine Zeitmessung eingebaut.
Bei 47416 Datensätzen dauert
das Laden aus der
DB: 17 Sek.
das Füllen des Listview: 232 Sek.
das Speichern (mit deinem Fehler): 398 Sek. (weil ja fehlerhafterweise jeder Datensatz mit Insert neu eingefügt wird).
Damit könnte keiner arbeiten. Selbst wenn du den Fehler beseitigst, wird die Zeit für das Speichern nicht so kleiner, dass es komfortabel wäre, denn es würde ja auch jeder Datensatz trotzdem gespeichert, nur halt mit Update.
Abhilfe, bei jetzigem Programmaufbau, würde z.B. eine Hilfevariable im Customer-Object schaffen. Du könnte in der TCustomer-Klasse noch die Property Modified als Boolean einfügen, die im Constructor Create erst einmal auf False gesetzt wird.
Wird nun ein Datensatz verändert, oder hinzugefügt, so wird CustomerList[x].Modified bzw. Customer.Modified auf True gesetzt.
In der SaveToDB-Routine könntest du nun erst einmal auf Modified prüfen und so entscheiden, ob der Datensatz überhaupt gespeichert werden muss. So hättest du die Zeit für das Speichern auf wenige Sekunden oder Millisekunden reduziert. Darfst aber nicht vergessen, nach dem Speichern des Datensatzes Modified wieder auf False zu setzen.
Sinnvoll wäre auch, nach dem editieren den zugehörigen ListView-Eintrag gleich zu aktualisieren, damit nach dem SaveToDB auch wirklich das richtige im Listview steht (ist natürlich suboptimal, aber bei jetzigem Programmaufbau am sinnvollsten).
Ähnliches Problem besteht beim löschen eines Datensatzes. Zur Zeit löscht du ihn nur aus der CustomerList und machst anschließend ein FuelleListView. Damit ist er zwar aus der Liste, aber in der
DB immer noch vorhanden und beim nächsten Laden wieder da.
Außerdem dauert das FuelleListView bei 47416 Datensätzen ja fast 4 Minuten. Also inakzeptabel.
Hier hättest du 2 Möglichkeiten, entweder du entfernst per
SQL den Datensatz gleich aus der
DB und den dazugehörigen Eintrag aus der ListView, oder du machst es wie oben mit einer Hilfsproperty, die z.B. Deleted heißen könnte. Auf die müsstest du dann aber in der SaveToDB auch eingehen, und ein passendes Delete-Statement für
SQL bereitstellen.
Was die Zeit angeht, die das Listview benötigt, bis alles Daten der CustomerList dort vorhanden ist, so wird man dort wohl keine signifikante Geschwindigkeitssteigerung erreichen. Zumindest nicht mit Möglichkeiten, die du jetzt hier auch verstehen würdest. Für diesen Fall würde sich aber ein VirtualStringTree gerade zu aufdrängen. Das ist zwar vom Handling her etwas komplizierter, aber wenn man die Arbeitsweise erst mal verstanden hat, schon fast genial. Und in deinem Fall gut einsetzbar, da du bereit die passenden Objecte vorliegen hast.
Und für alle anderen, die das jetzt gelesen haben: Sicherlich gibt es wesentlich bessere Möglichkeiten das speichern der Daten so zu realisieren, damit viele der oben genannten Schritte gar nicht notwendig wären. Aber ich wollte EdAdvokat erst mal nur die Möglichkeiten und Probleme aufzeigen, ohne Ihn vollends zu verwirren.