SQL Server: datediff-Funktion führte zu einem überlauf

Was hat dieser Fehler zu bedeuten und wie kann ich Sie vermeiden?

Die datediff-Funktion führte zu einem überlauf. Die Anzahl der dateparts zwischen zwei Datum/Uhrzeit-Instanzen ist zu groß. Versuchen datediff mit einem weniger präzisen datepart.

Ich bin nicht mit der datediff-Funktion. Ich mache diese Abfrage wo Timestamp ein datetime-Typ:

SELECT TOP 10 * from vSomeView 
WHERE TimestampUTC >= '2009-08-13 22:17:00'

Was könnte ich falsch gemacht?

Ich bin mit SQL Server 2008.

  • was passiert in der Ansicht?
  • Basierend auf den Namen "vSomeView", es klingt wie Sie der Abfrage anzeigen. Wenn ja, was ist die view-definition? Vielleicht ist es mit datepart?
  • Tut vSomeView verwenden der DateDiff?
  • Ich denke, timestamp ist ein reserviertes Wort ist.. aber es sieht aus wie Sie versuchen, es zu benutzen, wie den Namen einer Spalte aus? Geben Sie entweder den Namen der Tabelle, die erste, und/oder wählen Sie einen anderen Spaltennamen.
  • Der Blick ist zu tun, tun einen join zwischen zwei Tabellen und die Multiplikation einer anderen Spalte (nicht in dieser Abfrage) durch einen bestimmten Betrag. Die TimestampUTC Spalte nicht geändert und DateDiff wird nicht verwendet.
  • Keine Sorge... sind Sie sicher, dass die multplication nicht versehentlich verursacht den überlauf?
  • Sind die Basis-Tabellen mit berechneten Spalten? Sind Sie in der Lage, zu vernehmen die Tabellen erfolgreich, ohne den Blick? Oder die Ansicht ohne die where-Klausel?
  • Poste bitte die view-definition. Auch, überprüfen Sie bitte die referenzierten Objekte in den Blick, auf der off-chance, dass Sie auch die Ansichten oder die vielleicht sogar funktioniert.
  • Überprüfen Sie auch für Trigger auf der Basis von Tabellen. Manchmal auch skurrile Fehler zurückgegeben, da gibt es einen bug in einem trigger.
  • Gute Tipps für die Behandlung dieses.

InformationsquelleAutor | 2009-08-13
  1. 12

    SQL Server-vielleicht tut ein DATEDIFF intern für den Vergleich und wenn die beiden Termine sind so viel mehr als 68 Jahre auseinander (und der interne DATEDIFF ist in Sekunden), DATEDIFF können Fehler wie die Ausgabe von DATEDIFF ist ein INT.

    Hab ich stieß auf dieses vor (mit DATEDIFF direkt) gelöst und durch Gießen DATETIME ist an Dezimalstellen wie folgt:

    DECLARE @d1 DATETIME
DECLARE @d2 DATETIME

DECLARE @n1 AS DECIMAL(38,20)
DECLARE @n2 AS DECIMAL(38,20)

SET @d1 = '2 Jan 2000 00:00:02'
SET @d2 = '1 Jan 2000 00:00:00'

-- @n1 and @n2 will hold the datetime in fractional form. The integer part
-- is the #days since 1 Jan 1900, whilst the fractional part is the time in
-- 1/86400's of a second (24 hours = 86400 seconds, so a fraction of 0.5
-- represents 12:00:00 noon precisely.
SELECT @n1 = CAST(@d1 AS DECIMAL(38,20)), @n2 = CAST(@d2 AS DECIMAL(38,20))

-- Now manipulate the fractional and integer parts of the time
-- to get the final seconds difference.
SELECT CAST(86400 AS DECIMAL(38,20)) * (@n1 - @n2)
    • Ich glaube nicht, dass es funktioniert auf diese Weise. Wenn TimestampUTC ist ein datetime(die da sagt, es ist) - oder smalldatetime -, SQL konvertieren '2009-08-13 22:17:00' in den gleichen Datentyp, und dann ist es nur eine einfache Binär-Wert-Vergleich der internen Darstellungen einer datetime.
    • Sie könnten Recht haben. Ich habe nicht Zugriff auf einen 2008-box, aber ich tun, um 2005. Habe keine Zeit zu Experimentieren, aber dabei einige Stossen jetzt und ich kann nicht die beschriebenen Fehler auftreten. Es wäre nützlich zu sehen, die definition der SICHT, aber die oben genannte Methode kann in der Lage sein, das Problem zu beheben, wenn die Versagen DATEDIFF zurückgeführt werden kann.
    InformationsquelleAutor Chris J
  2. 4

    Ich hatte das gleiche Problem, weil einer der Datensätze in meine Tabelle ein default-Wert für einen DatumUhrzeit-Feld 1900-01-01 00:00:00.000.

    SELECT *
FROM Terminal 
WHERE DATEDIFF(SECOND, LastCheckIn, GETDATE()) < 30

    DATEDIFF in der where-Klausel ausgewertet werden, die für alle Datensätze in der Tabelle und überlauf an der LastCheckIn mit Wert 1900-01-01 00:00:00.000

    Ich löste es, indem erste Bewertung DATEDIFF für eine Differenz in JAHREN < 1

    Dies ist die endgültige Abfrage:

    SELECT *
FROM Terminal 
WHERE
DATEDIFF(YEAR, LastCheckIn, GETDATE()) < 1
AND
DATEDIFF(SECOND, LastCheckIn, GETDATE()) < 30
    • Ich konnte nicht damit es funktioniert. Ich bin mit sqlserver 2012. IIRC, SQL-Server nicht mehr garantieren, um in der Auswertung der where-Klausel, und in meinem Fall, scheint immer bewerten beide Bedingungen.
    • Danke für diese Antwort! Ich hatte das gleiche Problem, in dem ein Datum in der Tabelle war das Jahr 0017 statt 2017... Aktualisieren das Datum fest, das overflow-Problem.
    InformationsquelleAutor Jazz
  3. 2

    Danke Euch allen für die Zeiger!

    Machten Sie mich überprüfen Sie die vSomeView und es stellt sich heraus, dass die vSomeView war dabei eine Verknüpfung zwischen einer Ansicht und einige andere Tabellen. Diese Sicht wurde dabei ein datediff konvertieren einige datetime in eine posix-Stil-Zeitstempel (Sekunden seit Epoche). Einmal habe ich es entfernt, die Abfrage läuft wunderbar.

    InformationsquelleAutor
  4. 0

    SQL Server 2016 Hinzugefügt DATEDIFF_BIG() gibt bigint.

    InformationsquelleAutor Taudris
Schreibe einen Kommentar