MSSQL - DateTime to Int liefert unterschiedliche Werte

[Aviator]

Zitat von Uwe Raabe:

Zitat von Aviator:

dass eine Abfrage ob das Datum >= 30.11.2020 ist keine Werte zurückliefert obwohl das eigentliche Belegdatum der 29.11.2020 ist.

Ist da vielleicht noch irgendwo ein Tippfehler?

Ja sorry. Genau anders herum. Es gibt ein Belegdatum und ein Startdatum ab wann die Prüfung laufen soll. Das Belegdatum muss >= dem Startdatum sein, damit es in die Prüfung mit einfließt.

Zitat von Delphi.Narium:

Siehe Doku:
https://docs.microsoft.com/de-de/sql...l-server-ver15
http://docs.embarcadero.com/products...TDateTime.html

MSSQL beginnt beim 1.1.1900
Delphi beginnt beim 30.12.1899

Das ergibt eine Differenz von exakt 2 Tagen.

Naja da würde ich mal sagen, dass das ein ganz klarer Fall von PEBKAC ist. Danke für die Info. Das war mir jetzt neu. Da muss ich mal prüfen, wo das evtl. überall Probleme bereiten könnte.

Die Frage wäre jetzt allerdings, ob es hierfür eine einfache Lösung gibt, ohne das ich jedes Mal daran denken muss die zwei Tage abzuziehen.

[Delphi.Narium]

Ja, die Lösung ist ganz einfach:

Datum als Datum speichern und nicht als Integer.

Oder:
Query.Parameters('DateParam').AsDateTime := StrToDate('30.11.2020');
Query.Parameters('DateParam').AsString := '30.11.2020';

[Aviator]

Hmm ... Wald und Bäume und so. Schaue ich mir direkt mal an ob es dann problemlos funktioniert.

[Bernhard Geyer]

Zitat von Delphi.Narium:

Ja, die Lösung ist ganz einfach:

Datum als Datum speichern und nicht als Integer.

Oder notfalls als String im ISO-Format (Haben wir, da vor 20 Jahren bei Einführung jedes DBMS noch wild eigenes Verhalten bei Datumswerten zeigte)

[Aviator]

Ok. Der Test hat etwas länger gedauert. Ein simples Benutzen von Parameter().AsDate hat einen Fehler geworfen. [FireDAC][Phys][ODBC][Microsoft][SQL Native Client]Optionales Feature wurde nicht implementiert . Ich habe jetzt einfach mal noch versucht auf den neuen ODBC Treiber umzustellen anstatt den Native Client zu benutzen. Da gab es dann noch ein paar Schwierigkeiten mit dem ConnectionString. Jetzt scheint es aber zu laufen und den Datensatz hat er auch gefunden.

Danke für die Hilfe. Jetzt weiß ich zumindest mal woher der Fehler kam.

[generic]

Kleiner Tip noch am Rande:
Ich sehe hier viele Funktionen, welche von den Ländereinstellungen abhängig sein.
z.B. StrToDate von den OS und die Convert-Funktionen von der Sprache im Server bzw. der Anmeldung.

Versucht hier am besten unabhängig zu werden von den L.Einstellungen.

Eine Lösung wurde bereits genannt, z.B. nicht zu konvertieren und überall die richtigen Datentypen zu verwenden.

[Aviator]

Zitat von generic:

Eine Lösung wurde bereits genannt, z.B. nicht zu konvertieren und überall die richtigen Datentypen zu verwenden.

Da werde ich zukünftig auch genauer darauf achten anstatt immer nur .Value zu nehmen. Der StrToDate() Aufruf war nur ein Beispiel um hier etwas zu demonstrieren. In Wirklichkeit wurde, wie ich im ersten Beitrag geschrieben hatte, ein TDate Wert aus einem anderen Objekt an den Parameter übergeben.

Trotzdem danke für den Hinweis.

[Delphi.Narium]

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.

[Redeemer]

In OLE beginnt die Epoche am 0. Januar des Schaltjahres 1900. Ja, es ist ausdrücklich nicht der 31. Dezember 1899 (formatiert mal in Excel 0 oder 60 als Datum). Und ja, 1900 war kein Schaltjahr.
Aus den Gründen hat Delphi den minus-1. Januar des Normaljahres 1900 (auch 30. Dezember 1899 genannt) als Start der Epoche. Bei Tagen ab dem 1.3.1900 kann man bei der Arbeit mit OLE den Unterschied ignorieren. OLE kennt keine Datumsangaben vor Beginn der Epoche.
Die Epoche beginnt bei SQL Server am 1. Januar des Normaljahres 1900. Warum Microsoft da ein anderes Datum als bei ihren anderen Produkten gewählt hat, erschließt sich mir nicht.

Da muss man höllisch bei überladenen Methoden aufpassen, die was an die Datenbank übergeben, da man in Delphi Double und TDateTime nicht unterscheiden kann, sonst hat man die zwei Tage Differenz.