Einzelnen Beitrag anzeigen

Delphi.Narium

Registriert seit: 27. Nov 2017
2.508 Beiträge
 
Delphi 7 Professional
 
#11

AW: MSSQL - DateTime to Int liefert unterschiedliche Werte

  Alt 12. Dez 2020, 11:32
Ein Datum ist bei mir immer .AsDateTime, egal welche Datenbank. Und wenn ich keine Uhrzeit habe? Ja und, dann ist es halt .AsDateTime um 0:00 Uhr.

Damit hatte ich noch nie irgendwelche Probleme. Mir war bis gestern nicht mal bekannt, dass es bei Delphi und MSSQL überhaupt die technische Möglichkeit gibt, einen "Zweitagesfehler" zu provozieren.

Bis jetzt (ca. 20 Jahre) musste ich mich nie um irgendeine Datumskonvertierung zwischen Delphi und einer beliebigen Datenbank kümmern. Die Schnittstellen haben das bisher immer transparent gemanagt. Damit umgehe ich auch eventuell mögliche Probleme, die durch unterschiedliche Ländereinstellungen bei Client / Server / Datenbank ggfls. für Probleme sorgen könnten. Die Datenbankschnittstellen sind eigentlich alle intelligent genug implementiert, um damit umgehen zu können.

.Value ist meiner Meinung nach die schlechtmöglichste Alternative: Das ist ein Variant. Und bei Varianten wird immer interpretiert, "was wohl am ehesten gemeint sein könnte". .Value ist für Typsicherheit eher ungeeignet.

Wenn ich 'nen String habe, nehme ich .AsString,
bei 'nem Integer .AsInteger,
bei 'nem Gleitkommawert .AsFloat,
bei 'nem Boolean .AsBoolean.

Warum nimmt man in Gottesnamen bei 'nem Date, Time, DateTime nicht .AsDateTime, sondern 'nen Integer? Nur weil man ein Datum ohne Uhrzeitanteil zufällig auch als Integer darstellen kann? (Bei Linux sind es übrigens Sekunden seit 1.1.1970, da wäre die Differenz irgendwie anders und wohl meist ein bisserl größer und garantiert nicht immer konstant.)

Bei 'nem String, der zufällig nur Ziffern (ohne Nachkommaanteil) enthält, nimmt doch auch nicht .AsInteger, nur weil das zufällig auch meistens klappt.

Ein String ist ein String.
Ein Integer ist ein Integer.
Ein Datum ist ein Datum.

.Value nehme ich nur, wenn ich nicht weiß was es ist und mir auch egal ist, was es ist. Hauptsache irgendwie rein in die Datenbank und ggfls. auch wieder irgendwie raus. Die, die dieses "Irgendwas" nutzen wollen, müssen sich dann selbst drum kümmern, dass sie damit auch was anfangen können. (Kommt in (meinem) täglichen Leben eher extrem selten bis garnicht vor )

Was auch gut geht: Hab' ich ein Datum nur als Zeichenfolge, dann nehme ich .AsString und konvertiere nicht selber. Die Datenbanksschnittstellen kriegen das gehändelt und jede Datenbank bekommt damit das für sie richtige Datumsformat. Und wenn das nicht klappt (weil die Zeichenfolge einen Wert enthält, der nicht in ein gültiges Datum verwandelt werden kann), dann fliegt 'ne Exception. Darauf kann man dann reagieren. Aber man muss garantiert nicht nach 'ner Zeitdifferenz suchen, die nur dadurch entstehen kann, dass man absolut ungeeignete Werte verwendet, die technisch zufällig von beiden Seiten "irgendwie" verstanden werden können.
  Mit Zitat antworten Zitat