Delphi-Quellcode:
// Wieso so:
ADOQuery1.FieldByName('TaskTermin').AsDateTime := StrToDateTime(DateToStr(aDate)+' '+TimeToStr(aTime))
//
// und nicht so: ?
ADOQuery1.FieldByName('TaskTermin').AsDateTime := aDate + aTime; // Oder -um sicher zu gehen : ' + trunc(aTime)
Zum Thema:
ADO macht einen auf den ersten blick sehr merkwürdigen Befehl zum ändern eines Datensatzes.
Code:
UPDATE Tabelle
Set Feld = <NeuerWert>
Where Feld = AlterWert
and Feld1 = AlterWert1
and Feld2 = AlterWert2
and Feld3 = AlterWert3
...
and FeldN = AlterWertN
Es wäre nun denkbar (weil z.B. Zeitwerte ja als Float abgelegt sind), das einer der Vergleiche nicht mehr hinhaut. Dann wird gar kein Datensatz verändert.
ADO prüft den Rückgabewert, der normalerweise aussieht wie '1 Row(s) updated'. Hier kommt aber '0 Row(s) updated' zurück und daher die Fehlermeldung. Die alten Werte hat sich dein
ADO geholt, als die Tabelle geladen wurde. In der Zwischenzeit könnte jemand anderes diesen Datensatz verändert haben und dann haut eben diese Abfrage nicht hin. Beispiel: Du lädst den Datensatz mit den Werte (1,2,3). Jemand anders ändert die 3 auf 4.
Nun kommt dein UPDATE-Befehl: 'Ändere im Datensatz (1,2,3) den Wert '3' auf '5'.... Nun gibt es diesen Datensatz ja nicht mehr (der heißt ja nun (1,2,4))...
ADO wird alle Felder in der 'WHERE'-Klausel aufführen, die in ihren ProviderFlags den Wert 'pfInWhere' gesetzt haben. Ich hoffe, deine Tabelle hat einen Primärschlüssel. Versuche also Folgendes: Lösche bei allen Feldern außer dem Primärschlüssel den Wert 'pfInWhere'. Setze 'pfInWhere' nur im Primärschlüsselfeld.
Das sollte den Provider dazu bringen, den UPDATE-Befehl so zu ändern, wie man ihn erwartet:
Code:
UPDATE Tabelle
SET Feld = NeuerWert
WHERE PKFeld = Schlüssel
Damit wird der Datensatz immer gefunden und man erlebt keine Überraschungen. Vor allen Dingen bei 'Float'-Feldern, also Feldern mit Fließkommazahlen, knallt es hier immer wieder.