MSSQL - DateTime to Int liefert unterschiedliche Werte

[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.

Das sieht mir aber vollkommen korrekt aus. Der 29.11.2020 ist ja auch nicht größer oder gleich dem 30.11.2020

Ist da vielleicht noch irgendwo ein Tippfehler?

[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.