also das speichern geht bei mir wunderbar. Wenn gleich es auch sehr lange dauert.
Generell ist es natürlich besser, die veränderten Daten gleich zu speichern. Du brauchst lediglich zu dem Object TCustomer zwei Methoden zum Speichern und zum Löschen hinzufügen. Beim Speichern wieder die ID rüfen, wenn =-1 dann insert sonst update. Und in der Mainform rufst du die dann bei den Buttons passen auf.
Wenn du aber bei deiner bisherigen Form bleiben willst, dann setzt die bei gelöschten Datensätzen die ID einfach auf -2. dann kannst du in der SaveToDB auf id=-2 prüfen und statt insert bzw. update machst du dir noch einen Remove-Statement dazu. Allerdings müsstest du dann dort auch das dazugehörige Object löschen, damit du hinterher auch mit FuelleListView die Anzeige neu aufbauen kannst. Und du müsstest in der SaveToDB entweder
for i:=self.count-1 downto 0
machen, oder alle Object die ID=-2 habe erst nach dem Speichern und vor dem FuelleListview löschen.
Klinkt umständlich...ist es auch. Besser wie oben und gleich speichern, löschen und hinzufügen, und danach immer FuelleListView. Das hätte auch den Vorteil, dass dein Programm auch mit mehreren Clients funktionieren könnte. Denn zur Zeit würde ein Speichern der
DB immer die Änderungen überschreiben, die ein anderer User eventuell gerade gespeichert hat, oder sogar zu Datenverlust führen.
Stell dir mal vor, du und ein anderer User laden die
DB an 2 Rechnern. Jetzt löscht der andere einen Datensatz und speichert.
Anschließend änderst du den gleichen Datensatz. bei dir ist ja noch in der CustomerList vorhanden. Anschließend willst du speichern. Dein
SQL-Statement UPDATE kann diesen Datensatz aber nicht finden (where ID=:id) und speichert ihn dem zur Folge auch nicht. Weg isser. Und so ließen sich noch weitere Szenarien darstellen.