Ich habe hier eine Anwendung, die Datensätze nach einem Datums-Zeitwert auf die Millisekunde genau abfragen muss.

markieren

SQL-Code:

SELECT
 <Felder>
FROM
 <Tabelle>
WHERE
 <DateTimeFeld> = :dateParam

Beim Testen ist mir aufgefallen, dass ein Vergleich nur bis zur Sekunde genau funktioniert. Nach einem Blick in die Hilfe dachte ich mir, dass ich für den DateParam nur NumericScale auf 3 setzen muss, damit der Vergleich so exakt wie gewünscht funktioniert, leider hat das aber nichts gebracht. Als Workaround übergebe ich den Parameter als String auf 3 Nachkommastellen formatiert, aber schön geht anders. Hat jemand noch eine andere Idee?

Danke schon einmal fürs Lesen.

Von welchem Typ ist denn das DateTimeFeld auf Datenbankseite, time, date, datetime, datetime2, ...? (https://learn.microsoft.com/de-de/sq...l-server-ver16)

Die Genauigkeit des SQL Server Datetime Datentyps ist 3.33 ms. Das bedeutet, dass 05.03.2004 23:59:59.999 gerundet wird auf 06.03.2004 00:00:00.000. Sprich: Der ist nicht so genau, wie Du es haben möchtest.

Der Datentyp ist DateTime. Ob das jetzt auf 1/1000 oder 1/100 Sekunde genau ist, ist mir ehrlich gesagt wurscht, ich möchte es nur so genau wie möglich auswerten, damit ich zuverlässige Werte bekomme. Genauer gesagt geht es um eine Abfrage der Art

markieren

SQL-Code:

SELECT
  <Felder>
FROM
  <Tabelle>
WHERE
  <DateTimeFeld> > :dateParam OR (<DateTimeFeld> = :dateParam1 AND <StringFeld> > :stringParam)
ORDER BY
  <DateTimeFeld>, <StringFeld>

Versuche es bitte mal mit

markieren

SQL-Code:

SELECT
  <Felder>
FROM
  <Tabelle>
WHERE <DateTimeFeld> > CONVERT(DATETIME2, :dateParam, 121)
ORDER BY
  <DateTimeFeld>, <StringFeld>

in Delphi sinngemäß mit :dateParam := FormatDateTime(‘YYYY.MM.DD hh:nn:ss.zzz’,Now)

Genauso mache ich es derzeit, aber einen Datums-/Zeitwert als String-Parameter zu übergeben geht mir ganz gewaltig gegen den Strich (was ist, wenn sich das interne Ein-/Ausgabeformat einmal ändern sollte oder ähnliche Dinge?), deshalb ja meine Frage, ob man einen DateTime-Parameter in FireDAC mit entsprechender Genauigkeit definieren kann. NumericScale auf 3 zu setzen hat wie gesagt nicht zum Erfolg geführt.

Übergibt FireDAC das überhaupt als DateTime-Typ? Bzw. kennt es diesen Typ vom MSSQL?

z.B. PgDAC und andere behandeln einfach alles als String, was sie nicht kennen.

Wenn es das dann z.B. nur als 'hh:mm:ss' ohne .zzz übergibt, dann ginge natürlich bissl unwichtiger Kleinkram schonmal verloren.

Bei MariaDB (das alternative DBMS, das unsere Software unterstützt) habe ich den Datentyp seinerzeit angepasst, da funktioniert das auch mit dem DateTime-Parameter, nur bei MSSQL gehen mir die Tausendstel-Sekunden flöten. Aufgefallen ist mir das unter MSSQL 2022, möglicherweise passiert das auch bei älteren Versionen, das habe ich noch nicht ausprobieren können.

Der Datentyp 'DateTime' in MS-SQL-Server wird intern als ein 8-Byte-Feld gespeichert. Es ist in der Lage, einen Bereich von 1753-01-01 bis 9999-12-31 abzudecken, mit einer Genauigkeit von 0,00333 Sekunden. Es handelt sich also nicht um einen Gleitkommawert.

Der DateTime-Typ unter SQL-Server ist für die Speicherung von Zeitangaben, mit einer Genauigkeit von hunderstel Sekunden nicht geeignet. Dafür wäre DateTime2 besser. Einzige Möglichkeit, die mir einfällt wäre:

markieren

SQL-Code:

ALTER TABLE
  <Tabelle>
ALTER COLUMN
  <DateTimeFeld> DATETIME2(3);

Da der Datumsbereich DateTime eine Teilmenge von DateTime2 ist, sollte das ohne Datenverlust funktionieren.

Damit sollten sich dann Abfragen so, wie Du es möchtest und es mit MariaDB funktioniert, auch mit dem SQL-Server (ohne Typkonvertierung) gestalten lassen.

BCD mit 1 Byte pro Wert, bzw. 2 für das Jahr auch nicht (YYMDHNSz), da 0.00333*256 nicht 1 ergibt.

Aber dennoch kann des ein Double sein, oder ein Int64 (ala Unix-Timestamp)
oder BCD mit ein paar verschobenen Bits.

Wenn der Typ nicht mit dem internen Format übertragen wird, wäre es aber auch egal.