Änderungen an DateTimePicker wird eine ADO Exception

[Dejan Vu]

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.