MSSQL - DateTime to Int liefert unterschiedliche Werte

[Aviator]

Hallo zusammen,

ich habe hier ein doch recht kurioses Problem mit MSSQL und Delphi.

Ich rufe Datensätze aus der Datenbank ab, die nach einem Datum eingeschränkt werden sollen. In diese speziellen Beispiel wird abgefragt, ob das Belegdatum größer oder gleich dem übergebenen Datum ist. Anfänglich ist mir das gar nicht aufgefallen, doch jetzt stelle ich fest, dass eine Abfrage ob das Datum >= 30.11.2020 ist keine Werte zurückliefert obwohl das eigentliche Belegdatum der 29.11.2020 ist.

Das Statement wird mit Parametern an den Server übergeben. Also als Beispiel mit

Delphi-Quellcode:

Query.Parameters('DateParam').Value := StrToDate('30.11.2020');

. Der echte Wert den ich hier übergebe kommt aus einer anderen Datenbank.

Ich habe nun mit dem SQL Profiler die Query abgefangen die an den Server gesendet wird. Wenn ich diese manuell auf dem Server ausführe kommt ebenfalls kein Ergebnis. Setze ich den Integer Wert in den das Datum bei der Übergabe umgewandelt wird um einen Tag zurück (also Integer - 1), dann wird der Datensatz angezeigt.

Baue ich mir jetzt auf dem SQL Server eine Query zusammen die mir aus einem Datum einen Integer und aus einem Integer ein Datum macht, dann unterscheiden sich die Werte von dem, was Delphi an die Datenbank übergibt. Eine Prüfung auf einer Website liefert allerdings das gleiche Ergebnis wie das von Delphi.


Der Wert 43831 liefert in Delphi als Datum 01.01.2020. Die folgende SQL Abfrage liefert auf dem Server allerdings als Datum dem 03.01.2020.

SQL-Code:

DECLARE @d1 int = 43831
SELECT CONVERT(datetime, @d1, 104)

Umgekehrt herum zeigt der SQL Server beim Konvertieren des Datums in einen Integer Wert den gleichen Wert an, in das er auch dieses Datum umwandelt. Also in sich ist der SQL Server korrekt. Nur die Werte passen nicht zu denen von Delphi und der Website.

Diese Abfrage liefert als Ergebnis 43831. Bei Delphi ist dieser Wert aber bereits der 01.01.2020.

SQL-Code:

DECLARE @d1 datetime = '03.01.2020 00:00:00'
SELECT CONVERT(INT, CONVERT(DATETIME, @d1))

Das müsste doch schon irgendjemandem bereits aufgefallen sein. Es sind also immer zwei Tage Differenz zwischen Delphi und MSSQL.

Hat das jemand eine Idee was hier schief gehen könnte.

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

[Uwe Raabe]

Zitat:

Zitat von Aviator (Beitrag 1478941)

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 :gruebel:

Ist da vielleicht noch irgendwo ein Tippfehler?

[Aviator]

Zitat:

Zitat von Uwe Raabe (Beitrag 1478948)

Zitat:

Zitat von Aviator (Beitrag 1478941)

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:

Zitat von Delphi.Narium (Beitrag 1478947)

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:

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Delphi.Narium (Beitrag 1478950)

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.

Delphi-Quellcode:

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

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

Zitat von generic (Beitrag 1478986)

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

Delphi-Quellcode:

.Value

zu nehmen. Der

Delphi-Quellcode:

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. :)